[email protected]
[Top] [All Lists]

Proposed Resolution of Comments (Was: Composite Link Requirements)

Subject: Proposed Resolution of Comments Was: Composite Link Requirements
From: "Mcdysan, David E"
Date: Tue, 2 Mar 2010 09:25:16 -0500
Hi Curtis,

The co-authors of this draft reviewed your comments and decided to
respond with three separate messages, to separate the threads as follows
so that all of the issues you raise can be resolved efficiently.

        #1 Composite Link Trademark Issue (Was: Composite Link
Requirements)
        #2. Acknowledgement of Prior Work (Was: Composite Link
Requirements)
        #3. Proposed Resolution of Comments (Was: Composite Link
Requirements)

This is thread #3.

Dave   

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> On Behalf Of Curtis Villamizar
> Sent: Saturday, February 27, 2010 4:00 AM
> To: [email protected]
> Subject: Composite Link Requirements
> 
> 
> Hi there good people of RTGWG,
> 
> This is in regards to the goals that are embodied in the 
> RTGWG acceptance of a draft to deal with requirements for 
> composite link, currently named draft-ietf-rtgwg-cl-requirement-00.txt
> 
> 
> I'm bringing up two issues in this email.  One is prior 
> composite link work and the other is prior methods of 
> handling composite link, which should be acknowledged.  

This is the basis for thread#3.

> After 
> that I just have some comments and questions on the draft.

Text Snipped

> 
> Comments on the draft:
> 
> The following statements may be inaccurate:
> 
>    The Link Bundle concept is somewhat limited because of the
>    requirement that all component links must have identical
>    capabilities, and because it applies only to TE links.
> 
>      This may be inaccurate.  I don't think there is a requirement
>      that a link bundle use identical links.
> 
>      In any case, both Avici composite links and many LAG
>      implementations allow a mix of member speeds and neither was
>      applicable to TE links only.

Not clear what specific text change is being proposed. Does the
following address your comment?

EXISTING 3.1 TEXT 
   o  Advertisement of each component link into the IGP. Although this
      would address the problem, it has a scaling impact on IGP routing,
      and was an important motivation for the specification of link
      bundling [RFC4201]. However, there are two gaps in link bundling:

         1.  It only supports RSVP-TE, not LDP.

           2.  It does not support a set of component links with
different
      characteristics (e.g., different bandwidth and/or latency).

      For example, in practice carriers commonly use link bandwidth and
      link latency to set link TE metrics for RSVP-TE.  For RSVP-TE,
      limiting the component links to same TE metric has the practical
      effect of dis-allowing component links with different link
      bandwidth and latencies.

PROPOSED TEXT

   o  Advertisement of each component link into the IGP. Although this
      would address the problem, it has a scaling impact on IGP routing,
      and was an important motivation for the specification of link
      bundling [RFC4201]. However, there are two gaps in link bundling:

         1.  It only supports RSVP-TE, not LDP.

           2.  It only supports advertisement of a single TE metric for 
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
        a set of component links, 

        However, the component links in this set may have different
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
        characteristics (e.g., different bandwidth and/or latency).
      For example, in practice carriers commonly use link bandwidth and
      link latency to set link TE metrics for RSVP-TE.  For RSVP-TE,
      limiting the component links to same TE metric has the practical
      effect of dis-allowing component links with different link
      bandwidth and latencies.

> 
> The following should be replaced:
> 
>    Traffic Flow: A set of packets that with common identifier
>    characteristics that the composite link is able to use to aggregate
>    traffic into Connections.  Identifiers can be an MPLS label stack
>    or any combination of IP addresses and protocol types for routing,
>    signaling and management packets.
> 
> Diffserv already defined a microflow to be the same thing.  
> We should not invent new terms to mean the same thing as 
> existing terms.  We can just point out that labels can also 
> be used to identify a microflow.

A clear definition is certainly the goal. Can you provide a specific
Diffserv reference for review by the Working Group. 

> 
> This statement is definitely inaccurate for a number of reasons:
> 
>    o  ECMP/Hashing/LAG: IP traffic composed of a large number of flows
>       with bandwidth that is small with respect to the individual link
>       capacity can be handled relatively well using ECMP/LAG
>       approaches.  However, ?many/some of? these approaches do not
make use of MPLS
                              ^^^^^^^^^^^^^^
>       control plane information nor traffic volume
>       information. Distribution techniques applied only within the
>       data plane can result in less than ideal load balancing across
>       component links of a composite link.
> 
>   Avici used feedback from the egress port to the ingress port on
>   traffic volume and queue occupancy to influence the distribution of
>   the hash.  There is nothing in the definition of ECMP to prohibit
>   this and the OMP technique explicitly called for doing so and
>   proposed protocol extension to be able to go beyond just a decision
>   within a single NE as Avici did.

Does above proposed change address (part of your comment)? If so, should
this state many or some? Other parts of your comment seem to be solution
oriented and should certainly be considered to meet issues raised in the
requirements or included in the proposed framework draft.

> 
> This is inaccurate:
> 
>   o 2.  It does not support a set of component links with different
>         characteristics (e.g., different bandwidth and/or latency).
> 
>       For example, in practice carriers commonly use link bandwidth
>       and link latency to set link TE metrics for RSVP-TE.  For
>       RSVP-TE, limiting the component links to same TE metric has the
>       practical effect of dis-allowing component links with different
>       link bandwidth and latencies.
> 
> There is no formal meaning to the link metric in ISIS or OSPF.

See proposed rewording above.

> 
> Under inverse-mux: the real problem with inverse-mux is the 
> amount of bandwidth that needs to be multiplexed greatly 
> exceeds the fastest single packet processing element and 
> therefore doesn't work.  

This is true (we may want to state this as the bandwidth of any
"connection" as defined in the draft instead of "packet processing
element"). We recommend adding this to the Inverse Multiplexing bullet
in the motivation section.

> The latency argument is not really valid.

Please elaborate.

> 
> I think that the ability of an LSR to measure latency on and 
> LSP and report a latency figure or route based on lowest 
> latency is almost orthogonal to the problem of composite 
> link.  If latency and bandwidth at each holding priority is 
> advertised, then we have a cross product of advertisements.  
> For example, you can have 1 Gb/s at 10msec at pri#1, but if 
> you can live with 12msec you can have 2Gb/s, or at 14 msec 
> 3Gb/s, but at pri#2 you only get ... and so on for 8 priorities.
> Is this what we're aiming for?

Advertising each link would solve the problem (see second bullet in
motivation section), but creates more advertisements in the IGP and may
not work well with LDP.

> 
> The table at the beginning of seciton 4 is meaningless.

Do you believe that the text above the table is sufficient to define
these terms, which are used in the outline? Amongst the co-authors
agreeing on the meaning of these terms used to structure the outline
based upon prior comments was viewed as useful. Do other members of the
rtgwg want to delete this table, refine the definitions, or propose
specific changes to the requirements outline? 

> 
> In this section:
> 
>   4.1.1.1. Traffic Flow and Connection Mapping
> 
>    The solution SHALL support operator assignment of traffic flows to
>    specific connections.
> 
>    The solution SHALL support operator assignment of connections to
>    specific component links.
> 
> How is this supposed to work for signaled LSP where the 
> component links are not idendified in control signaling?  Is 
> this scalable from a configuration standpoint or only 
> applicable to staticly configured MPLS cross connect?

A future solution could identify component links. The wg direction for
this draft was to focus on requirements. These comments may be
applicable to the framework draft or a specific proposed solution.

> 
>    In order to prevent packet loss, the solution must employ make-
>    before-break when a change in the mapping of a connection to a
>    component link mapping change has to occur.
> 
> Only the ingress of an LSP can initiate make-before-break and 
> the ingress doesn't know about the component links.  In 
> RFC3209, make-before-break involves a new LSP using the same 
> tunnel-id.
> Are you using a different meaning for make-before-break?
> 
Good point. This is more like MPLS FRR at an intermediate point where
the bypass tunnel is first established before switching. Will clarify
this point and provide appropriate reference(s).

> Regarding this statelent:
> 
>    The solution SHALL support management plane controlled parameters
>    that define at least a minimum bandwidth, maximum bandwidth,
>    preemption priority, and holding priority for each connection
>    without TE information (i.e., LDP signaled LSP that does not
>    contain the same information as an RSVP-TE signaled LSP).
> 
> Could you explain how preemption would work for LDP?  Do you 
> plane to withdraw the FEC?  If so, for how long?  Forever?  
> If not forever would the traffic periodically come back, get 
> remeasured and withdrawn again?

Good questions, but they seem solution oriented. The wg direction for
this draft was to focus on requirements. These comments may be
applicable to the framework draft or a specific proposed solution. Would
you propose a rewording, clarification of the requirement, and/or
additional requirements? 

> 
> In 4.2.2.1 what does this mean?
> 
>    o  Bandwidth of the highest and lowest speed

We discussed this and propose the following replacement:

o Maximum and minimum acceptable bandwidth of the LSP

> 
> Overall I find many of the stated requirements to be unclear. 
>  Perhaps some discussion and improvements to the wording will 
> bring clarity.

Achieving clarity is certainly our shared wg goal. Specific questions
and comments like those Curtis has provided would be most appreciated by
the co-authors.

> Or maybe I'm just dense.
> 
> Curtis
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
> 
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

<Prev in Thread] Current Thread [Next in Thread>