Thanks Acee. Gyan
On Mon, Nov 30, 2020 at 3:39 PM Acee Lindem (acee) <[email protected]> wrote: > Speaking as LSR Co-Chair: > > > > Hi Gyan, > > This is more a discussion for the 6MAN WG. Here is the charter for the LSR > WG: https://datatracker.ietf.org/wg/lsr/about/ > > No need to cross-post to the LSR list… > > Thanks, > > Acee > > > > *From: *Lsr <[email protected]> on behalf of Gyan Mishra < > [email protected]> > *Date: *Monday, November 30, 2020 at 3:22 PM > *To: *lsr <[email protected]> > *Subject: *[Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP / > LAG / MLAG hash > > > > > > Dear LSR WG experts, > > > > > > Does anyone know if vendors have started or plan to start supporting IPv6 > flow label 5-tuple dscp marking for ECMP hashing. > > > > IPv6 flow label support for ECMP > > > > https://tools.ietf.org/html/rfc6437 > > > > IPv4 has traditionally always utilized recommended BCP of flow based load > balancing due to issues related to out of order and reordering of packets. > Although per packet load balancing is supported by most vendors it is not > recommended due to forwarding plane impact. > > > > This IPv6 flow label feature of 5-tuple hash provides significant > advantages for operators much needed ECMP load balancing entropy as compare > to traditional “flow or session” based load balancing which is the case as > well with MPLS entropy label RFC 6790 load balancing contrasted below. > > > > IPv6 flow label has significant benefits for operators deploying SRv6 > which utilizes the IPv6 data plane to now have “native” built in ECMP > entropy as part of the protocol as compare to its predecessor IPv4. > > > > This gives SRv6 another significant edge over MPLS predecessor. > > > > Excerpt from RFC 6437: > > > > Forwarding nodes such as routers and load distributors MUST NOT > > depend only on Flow Label values being uniformly distributed. In > > any usage such as a hash key for load distribution, the Flow Label > > bits MUST be combined at least with bits from other sources within > > the packet, so as to produce a constant hash value for each flow > > and a suitable distribution of hash values across flows. > > Typically, the other fields used will be some or all components of > > the usual 5-tuple. In this way, load distribution will still > > occur even if the Flow Label values are poorly distributed. > > > > Although uniformly distributed flow label values are recommended > > below, and will always be helpful for load distribution, it is unsafe > > to assume their presence in the general case, and the use case needs > > to work even if the flow label value is zero. > > > > As a general practice, packet flows should not be reordered, and the > > use of the Flow Label field does not affect this. In particular, a > > Flow label value of zero does not imply that reordering is > > acceptable. > > > > > > Below comparison of IPv6 flow label benefits over MPLS entropy label: > > > > > > ! MPLS Entropy label > > https://tools.ietf.org/html/rfc6790 > > > > > > > > As a comparison to MPLS entropy label, the mpls entropy label reduces the > control plane label binding and LFIB forwarding plane data structure by not > having a per ECMP path label allocation per FEC by adding an additional > entropy label to the label stack. > > > > > > However MPLS entropy label is still uses the traditional flow or session > based load balancing algorithm which results in > > uneven load balancing. > > > > > > Kind Regards > > > > Gyan > > > > > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
