The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <4B6D09F3B826D411A67300D0B706EFDE0115C836@nt-exch-yow.pmc-sierra.bc.
ca>, Shahram Davari writes:
> I think you misunderstood me. I said using the first nibble after bottom-most
>  MPLS label to
> identify IP header, so that it could be used as part of the hash key, is some
> thing new and proprietary (after MPLS was invented) and is not even documente
> d in any informational or standard RFC including RFC2991. After all you could
>  use the MPLS labels only for hash key.

A PID is not non-standard and proprietary if it is standardized and
that is what we are discussing.

> Do you think that all hashing key selection algorithms by all vendors should 
> be supported
> by all IETF standards? What if one decides to use CRC to distinguish IP packe
> ts? should IETF
> standards be backward compatible with that too?
> 
> -Shahram

RFC2991 is fine as is.  Load balancing algorithms exist.  There is no
need to standardize them.  Some are based on hashing.

Curtis


> >-----Original Message-----
> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
> >Sent: Wednesday, March 26, 2003 5:05 PM
> >To: Shahram Davari
> >Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; Andrew G.
> >Malis; 'mpls@uu.net'; tnadeau@cisco.com
> >Subject: Re: [PWE3] MPLS PID 
> >
> >
> >
> >In message 
> ><4B6D09F3B826D411A67300D0B706EFDE0115C831@nt-exch-yow.pmc-sierra.bc.
> >ca>, Shahram Davari writes:
> >>  
> >> >>1) ECMP could use only label hashing and not hash IP header.
> >> >
> >> >         This is unrealistic. Lots of vendors hash on both,
> >> >one or the other.  Lets not go down the road of trying
> >> >to mandate how ECMP works again. We went down that
> >> >road in MPLS and the response was clear.
> >>  
> >> Hashing on IP header is not part of any IETF standard, and I am not
> >> sure all fu ture IETF standards should be based on supporting
> >> non-standard proprietary implementation s. if one likes to still hash
> >> IP header, then he could define a proper protocol mux header and use
> >> it all the time.
> >
> >
> >You keep repeating this "non-standard proprietary" diatribe despite
> >being corrected.
> >
> >src/dst based hash has been used for almost 15 years now.  In 1988 you
> >might have been more justified in calling it "non-standard
> >proprietary" but not in 2003.
> >
> >It is documented in RFC 2991.
> >
> >  2991 Multipath Issues in Unicast and Multicast Next-Hop Selection. D.
> >       Thaler, C. Hopps. November 2000. (Format: TXT=17796 
> >bytes) (Status:
> >       INFORMATIONAL)
> >
> >This makes it far from proprietary and the fact that the document as
> >informational does not make it non-standard.  It is not mandated by
> >any specific protocol but it is widely implemented and deployed.
> >
> >src/dst hash based load split is widely deployed in numerous protocol
> >and considered important by many ISPs.
> >
> >So please stop making the "non-standard proprietary" accusation unless
> >you want to be known as someone who persistantly ignores the facts.
> >
> >Curtis
> >
>