Re: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP / LAG / MLAG hash

[Gyan Mishra <[e-mail]>]

Understood.  I think the gap as you stated as far as ECMP hash algorithm
for IPv6 is vendor specific implementation which is independent of LSR.
This is a vendor implementation question and not a LSR question.

Cheers,

Gyan

On Mon, Nov 30, 2020 at 4:28 PM Acee Lindem (acee) <[e-mail]> wrote:

> There is nothing in OSPF or IS-IS protocols related to the ECMP
> load-balancing with respect to the flow label. RFC 6437 is an IPv6 WG
> (predecessor of 6MAN) document. Are you just trying to torment me 😉
>
>
>
> Acee
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Monday, November 30, 2020 at 4:23 PM
> *To: *Acee Lindem <[e-mail]>
> *Cc: *lsr <[e-mail]>
> *Subject: *Re: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP
> / LAG / MLAG hash
>
>
>
> Hi Acee
>
>
>
> 6MAN deals with the IPv6 protocol specifications and not routing protocols
> in the ECMP load balancing framework.
>
>
>
> 6MAN would not have any idea if ISIS or OSPF AFI IPv6 5-tuple ECMP load
> balancing is supported and industry direction to support this critical
> feature from a IGP perspective.
>
>
>
> This question posed is in the context of LSR IGP load balancing framework,
> OSPF & ISIS  AFI IPv6 use of RFC 6437 for 5-tuple hash ECMP load balancing
> for even 50/50 load balancing hash as opposed to router default flow or
> session based load balancing.
>
>
>
> Any feedback related in this context is  much appreciated.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Mon, Nov 30, 2020 at 3:39 PM Acee Lindem (acee) <[e-mail]> 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 <[e-mail]> on behalf of Gyan Mishra <
> [e-mail]>
> *Date: *Monday, November 30, 2020 at 3:22 PM
> *To: *lsr <[e-mail]>
> *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
>
>
>
>
>
> --
>
> *Error! Filename not specified.* <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
>
>
>
> --
>
> [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