[email protected]
[Top] [All Lists]

FW: composite link - candidate for respin, maybe

Subject: FW: composite link - candidate for respin, maybe
From: Yong Lucy
Date: Sun, 28 Mar 2010 17:52:08 -0500

Thank you for this work. You have a quick and good start.
See inline.


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Curtis Villamizar

> Sent: Friday, March 26, 2010 2:02 AM
> To: [email protected]
> Subject: composite link - candidate for respin, maybe
> This email is to the authors of the CL drafts and the WG as a whole.
> I started out writing a quick few bullets on what we talked about in
> today's WG meeting that we seemed to agree on and that made some sense
> to me.  The latter part may be a filter that introduces artifacts to
> the signal (or noise).
> That didn't seem to stand alone so I added some terms up front and
> then some introductory text, trying to keep it concise.
> What I would like to ask the WG is whether I'm on a reasonable track
> here.  [hopefully we won't have continued dead silence on the list.]
> What I would like to ask the authors is whether they would consider
> this a reasonable restart point.
[LY] This is reasonable to me. 
> I've tried to keep in mind the chair's instructions and what I sensed
> to be the feelings in the audience (though we didn't formally hum - is
> formal WG hum an oxymoron?).
>   keep it short - 5 pages including boilerplate if possible
[LY] We understand what that imply. Not necessary to limit to 5, concise is
the goal.
>   include clear requirements
>   do not mandate implementation details
> I'm not sure if the usage scenarios at the end are needed or if this
> could stand alone.
> There was a lot of chatter in the room so I appologize if I missed
> something.  This is based on my recollection which is known to have a
> fairly high bit error rate even on better days.
> Curtis
> btw - this is obviously not an I-D as is for more reasons than missing
> boilerplate.  Its also late and I'm tired so I made no attempt to get
> citation right.
> Key terms:
>   flow - A flow in the context of this document is a aggregate of
>     traffic for which packets should not be reordered.  A flow is
>     similart to a microflow or ordered aggregate as defined in
>     [diffserv framework].  The term "flow" is used here for brevity.
>     This definition of flow should not be interpreted to have broader
>     scope than this document.
>   flow identification - The means of identifying a flow or a group of
>     flows may be specific to a type of payload.
[LY] IMO: in the context of this draft, flow identification identifies a
flow. Not a group of flows. A flow has to be transported over a single
component link in order to preserve the ordering.
>   top label entry - In MPLS the top label entry contains the label on
>     which an intitial forwarding decision is made.  This label may be
>     popped and the forwarding decision may involve further labels but
>     that is immeterial to this discussion.
>   label stack - In MPLS the label stack includes all of the MPLS
>     labels from the top of the stack to the label marked with the
>     S-bit (Bottom of Stack bit) set.
>   outer and inner LSP - The LSP associated with labels in the outer
>     encapsulation are called outer LSP.  Those LSP which are
>     associated with inner encapsulation (closer to the label entry
>     containing the S-bit) are called inner LSP.  These are not called
>     top and bottom LSP since MPLS and PWE draw the label stack in
>     opposite directions with PWE putting the outermost label on the
>     bottom of diagrams (and confusing people in doing so).
>   component link - See RFC4201.
[LY] IMO: component link in RFC 4201 apply to component links with the same
TE metrics. The component links in composite link support different
>   composite link - [pull from existing I-D]
> Introduction:
>   There is often a need to provide large aggregates of bandwidth that
>   is best provided using parallel links between routers or MPLS LSR.
>   In core networks there is often no alternative since the aggregate
>   capacities of core networks today far exceed the capacity of a
>   single physical link or single packet processing element.
>   Today this requirement can be handled by Ethernet Link Aggregation
>   [IEEE802.1X], link bundling [RFC4201], or other aggregation
>   techniques some of which may be vendor specific.  Each has strengths
>   and weaknesses.
>   The term composite link is more general than terms such as link
>   aggregate which is generally considered to be specific to Ethernet
>   and its use here is consistent with the broad definition in [ITU
>   8xxx].
>   Large aggregates of IP traffic do not provide explicit signaling to
>   indicate the expected traffic loads.  Large aggregates of MPLS
>   traffic are carried in MPLS tunnels supported by MPLS LSP.  LSP
>   which are signaled using RSVP-TE extensions do provide explicit
>   signaling which includes the expected traffic load for the
>   aggregate.  LSP which are signaled using LDP do not provide an
>   expected traffic load.
>   MPLS LSP may contain other MPLS LSP arranged hierarchically.  When
>   an MPLS LSR serves as a midpoint LSR in an LSP carrying other LSP as
>   payload, there is no signaling associated with these inner LSP.
>   Therefore even when using RSVP-TE signaling there may be
>   insufficient information provided by signaling to adequately
>   distribute load across a composite link.
[LY] FRR [LY] is a good example.
>   Generally a set of label stack entries that is unique across the
>   ordered set of label numbers can safely be assumed to contain a
>   group of flows.  The reordering of traffic can therefore be
>   considered to be acceptable unless reordering occurs within traffic
>   containing a common unique set of label stack entries.  Existing
>   load splitting techniques take advantage of this property in
>   addition to looking beyond the bottom of the label stack and
>   determining if the payload is IPv4 or IPv6 to load balance traffic
>   accordingly.
[LY] Does the draft aims on MPLS network? In MPLS network, there are IP
packets from control plane. Should we limit to this scope for now?
>   For example a large aggregate of IP traffic may be subdivided into a
>   large number of groups of flows using a hash on the IP source and
>   destination addresses.  This is as described in [diffserv
>   framework].  For MPLS traffic carrying IP, a similar hash can be
>   performed on the set of labels in the label stack.  These techniques
>   are both examples of means to subdivide traffic into groups of flows
>   for the purpose of load balancing traffic across aggregated link
>   capacity.  The means of identifying a flow should not be confused
>   with the definition of a flow.
>   Discussion of whether a hash based approach provides a sufficiently
>   even load balance using any particular hashing algorithm or method
>   of distributing traffic across a set of component links is outside
>   of the scope of this document.
>   The use of three hash based approaches are defined in RFCxxxx.  The
>   use of hash based approaches is mentioned as an example of an
>   existing set of techniques to distribute traffic over a set of
>   component links.  Other techniques are not precluded.
[LY] Not sure why mention hash here. 
> Requirements:
>   These requirements refer to link bundling solely to provide a frame
>   of reference.  This requirements document does not intend to
>   constrain a solution to build upon link bundling.  Meeting these
>   requirements useing extensions to link bundling is not precluded, if
>   doing so is determined by later IETF work to be the best solution.
>   The first few requirements listed here are met or partially met by
>   existing link bundling behavior including common behaviour that is
>   implemented when the all ones address (for example 0xFFFFFFFF for
>   IPv4) is used.  This common behaviour today makes use of a hashing
>   technique as described in the introduction, though other behaviours
>   are not precluded.
[LY] Why mention hash here?
>   1.  Aggregated control information which summarizes multiple
>       parallel links into a single advertisement is required to reduce
>       information load and improve scaleability.
>   2.  A means to support very large LSP is needed, including LSP whose
>       total bandwidth exceeds the size of a single component link but
>       whose traffic has no single flow greater the component links.
>       In link bundling this is supported by many implementations using
>       the all ones address component addressing and hash based
>       techniques.
[LY] IMO: This is not a requirement for composite link. Original draft
requires a flow BW (LSP) is less than single component link capacity.
Opinion from other co-authors? Original draft requires TE based method to
handle both RSVP-TE LSPs and LDP LSPs.
>       Note: some implementations impose further restrictions regarding
>       the distribution of traffic across the set of identifiers used
>       in flow identification.  Discussion of algorithms and
>       limitations of existing implementations is out of scope for this
>       requirements document.
>   The remaining requirements are not met by existing link bundling.
>   3.  In some more than one set of metrics is needed to accommodate a
>       mix of capacity with different characteristics, particularly a
>       bundle where a subset of component links have shorter delay.
>   4.  A mechansism is needed to signal an LSP such that a component
>       link with specific characteristics are chosen, if a preference
>       exists.  For example, the shortest delay may be required for
>       some LSP, but not required for others.
>   5.  LSP signaling is needed to indicate a preference for placement
>       on a single component link and to specifically forbid spreading
>       that LSP over multiple component links based on flow
>       identification beyond the outermost label entry.
>   6.  A means to support non-disruptive reallocation of an existing
>       LSP to another component link is needed.
>   7.  A means to populate the TE-LSDB with information regarding which
>       links (per end) can support distribution of large LSP across
>       multiple component links based on the component flows and the
>       characteristics of this capability.  Key characteristics are:
>       a.  The largest single flow that can be supported.  This may
>           or may not be related to the size of component links.
>       b.  Characteristics of the flow identification method.  [These
>           can be enumberated in this document or a later document. ]
>       c.  Other characteristics?  [ Not sure if I got everything
>           mentioned in the WG meeting. ]
>   8.  Some means is needed for an LSP which allows distribution of
>       flows across member links to indicate characteristics of flow
>       distribution.  These characteristics include:
>       a.  The largest flow expected.
>       b.  Other? [ Did we identify any other?  There was some
>           chatter about distribution of flows but no specific
>           characteristics was called for - AFAIK ]
>   9.  In some cases it may be useful to measure link parameters
>       and reflect these in metrics.  Link delay is an example.
>   10. Some uses require an ability to bound the sum of delay metrics
>       along a path while otherwise taking the shorted path related to
>       another metric.  [This was mentioned but seems a bit orthogonal
>       to all but #3.]
> Purpose:
>   [ A set of example scenarios were discussed.  We may want to capture
>     them here (and maybe refine the examples). ]
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg

rtgwg mailing list
[email protected]

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