[email protected]
[Top] [All Lists]

Acknowledgement of Prior Work (Was: Composite Link Requirements)

Subject: Acknowledgement of Prior Work Was: Composite Link Requirements
From: "Mcdysan, David E"
Date: Tue, 2 Mar 2010 09:25:12 -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
        #2. Acknowledgement of Prior Work (Was: Composite Link
        #3. Proposed Resolution of Comments (Was: Composite Link

This is thread #2.


> -----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 

This is the subject of this thread: 
> other is prior methods of 
> handling composite link, which should be acknowledged.  


> Note that ITU's G.800 does not define what a composite link 
> is and only mentions composite four times in the document, 
> including use of composite link and composite trail.  The 
> figure indicates that a composite link is "inverse 
> multiplexing".  For this reason, I don't think G.800 should 
> be referenced because its a big load of **** with only slight 
> mention of CL.

Part of the rtgwg acceptance of this a wg draft was to include a
reference to G.800. Lucy pointed out that the current text in section
2.2 is a paraphrase. We could replace with the following quote from
section 6.9.2 of G.800, if that is wg consensus:

"Multiple parallel links between the same subnetworks can be bundled
together into a single composite link. Each component link of the
composite link is independent in the sense that each component link is
supported by a separated service layer trail. The composite link conveys
communication information using different server layer trails thus the
sequence of symbols cross these links may not be preserved."

The text related to Inverse multiplexing is one of three cases in
section 6.9.2. The text above is the first case. G.800 states that these
are separate cases.

The text above Figure 16 in G.800 related to concatenated server trails
may also be relevant (at least in the framework).

So, the choices are replace current text with the direct quote, remove
the reference to G.800 and replace it with some other text.

WG comments?

Text Snipped

> Second issue is how CL has been handed in the past.
> Whether it was two links to two places that took completely 
> different paths (trails in ITU speak but this is IETF where 
> we say path), or two parallel links, this has been called 
> ECMP in IETF (and elsewhere) for two decades or more.  Both 
> ISIS and OSPF use the term ECMP.  The techniques used for 
> ECMP load balance was discussed on IETF lists quite a bit in 
> the early to mid-1990s.  The three techniques applied to IP 
> networks (in the terminology of that time) were:
>   1.  per packet load balance
>   2.  per bit or byte load balance aka bit striping or inverse-mux
>   3.  IP src/dst hash
> The second is applicable only to parallel links.  Using 
> larger chunks it is also the technique used in MPPP 
> (multilink PPP).  MPPP is also sometimes abbreviated PPP-ML, 
> though not in the RFC.  MPPP is no longer of much interest as 
> it was only applied to low speed links.
> The per packet load balance caused packet reorder and a great 
> deal of grief for service providers, hence the abundance of 
> discussion within IETF at the time.  The use of IP src/dst 
> hash, while widespread and widely discussed, did not get 
> documented in an RFC until Chris Hopps and Dave Thaler wrote 
> RFC 2991 "Multipath Issues in Unicast and Multicast Next-Hop 
> Selection" and RFC 2992 "Analysis of an Equal-Cost Multi-Path 
> Algorithm" in November 2000.  (at least AFAIK).
> The IP src/dst technique itself is beleived to have 
> originated in the T1-NSFNET, which puts its use back to circa 1987.
> The OMP work predates RFC 2991 and RFC 2992 but never made it 
> past the internet-draft stage.  In that work the use of 
> src/dst hash and the use of adaptive algorithms with src/dst 
> hash is discussed.  On the IETF mailing lists even methods of 
> implementation were discussed, table based and parallel sets 
> of comparator pairs (TCAM like).
> Circa 2000 there was a lot of discussion of the use of the 
> MPLS label stack to provide the entropy for ECMP vs looking 
> past the label stack at the IP payload.  Today's PW control 
> word acknowledges this common practice and avoids it for PW, 
> but the fat-pw aka entropy label puts better entropy back into PW.
> In practice today, all core hardware uses the same IP src/dst 
> hash to provide a load balance for ECMP and LAG.
> The existing internet-draft acknowledges link bundling, but 
> does not accurately characterize ECMP and LAG and the src/dst 
> hash technicque used by both, nor does it acknowledge the 
> prior OMP work.

The existing draft states some of these points already, but there is
certainly more background information that you provide. It seems that
you have more specific suggestions on the text in the draft and that is
where we propose specific changes to address your comments. Another
approach could be to add more text on IP-related load balancing as
compared with the MPLS-based load balancing which is the focus of the

Could you provide a URL for the prior OMP work that we can add as
informative reference.

Also, the scope of the draft is MPLS, which is not covered specifically
in the points above. 

Remainder of orignal message snipped.
rtgwg mailing list
[email protected]

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