The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Nov> msg00140



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

documenting ECMP - was on the mpls oam framework

  • From: "David Allan" <dallan@nortelnetworks.com>
  • Date: Tue, 18 Nov 2003 11:34:33 -0500
  • Cc: "'Rahul Aggarwal'" <rahul@juniper.net>, "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET

Curtis:

Unfortunately we're overlapping. IMHO what has been discussed is the
snooping and that implementations hash portions of or all of the stack. I'm
primarily interested in seeing the specific protocol permutations pinned
down instead of the blanket assume all permutations exist. In particular
w.r.t the label stack as I am aware of implementations that hash the bottom,
the top and would be very useful to know how much of the middle. 

If people are paranoid about publishing, perhaps feeding the information
through Loa anonymously would be a solution. However in the absence of
information other that what has appeared on the list, I'd consider the MUST
support ECMP requirement difficult to meet and would like to have somthing
to point to. I'd like to be able to know if the solution space has been
fully explored and the requirement has been met.

cheers
Dave

> Dave,
> 
> We've described all the ECMP methods in use either explicitly 
> in this email thread or through reference to RFC2991 and 
> RFC2992.  At least one implementation will split based on the 
> bandwidth configured for an RSVP/TE LSP rather than an equal 
> split.  Otherwise very few details have not been discussed.
> 
> Some implementations use only labels.  Some implementations 
> look for an IP header *if configured to do so* and hash the 
> IP src/dst, falling back to labels if the header is not IP.  
> Most implementations (probably all) limit label stack depth 
> before using hashed labels. Whether the bottom label of the 
> whole stack is hashed will varry.
> 
> You are not going to get the actual hash function itself and 
> the method of seeding it.  You also won't get a list of 
> companies and which feature is released in what version and 
> which line cards support what (that would be a competitive 
> analysis that is not needed for this sort of technical discussion).
> 
> What *relevant* detail are you missing?
> 
> Curtis
>