Re: [Bier] draft-ietf-bier-ipv6-requirements-09

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Gyan,

Please see zzh> below.

From: Gyan Mishra <[e-mail]>
Sent: Wednesday, November 18, 2020 10:14 AM
To: Alvaro Retana <[e-mail]>; BIER WG <[e-mail]>; Greg Shepherd <[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]>; Tony Przygienda <[e-mail]>; draft-ietf-bier-ipv6-requirements <[e-mail]>; [e-mail] <[e-mail]>
Subject: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]

All

I would like to thank the Greg, Tony and Alvaro on their pointers and guidance this morning to help move the ball forward with the requirements draft.

What I heard from Greg which rang out loud and clear and I mentioned to the requirements authors that today we have BIER MPLS where the BIER header is encoded into MPLS label stack layer 2 1/2 and we also have non MPLS BIER Ethernet ether type 0xAB37.

So why do we need non MPLS BIER encapsulation in an IPV6 environment as that IPv6 environment can be supported by non MPLS BIER Ethernet.  The case and point here is that eventually just as ATM and Frame Relay now live in the technology graveyard so will at some point in time as SRv6 matures will become the end all be all “core transport” mechanism for all operators.  So that being said we need a another encapsulation method to carry BIER , and per RFC 8296 that gap is filled with Non MPLS BIER Ethernet encapsulation today which will work for future SRv6 transport once MPLS goes by the wayside.

Zzh> First of all, the requirement draft does *not* mention SRv6 *at all*, and that’s a draft that have been worked on for almost two years.
Zzh> Secondly, SRv6 will still be on top of L2 links (whatever modern or graveyard L2 links). When BIER can work over L2 links directly, why bother add another layer.
Zzh> Finally, even if one wants to do SRv6 between BFIR and BFER just because SRv6 is taking over the world, it can be done with clean layering. Taking MVPN/EVPN with SRv6 as an example, you can first put on SRv6 header with a well-known multicast locator and a func/arg portion identifying the VPN. You can do fragmentation/ESP/whatever with it and then hand it to BIER for replication across the network, just like how you send an SRv6 packet across L2 links. This will avoid the problem of having to use the source address for identifying VPNs (I’ll follow up on my previous comments on draft-xie-bier-ipv6-mvpn).
Zzh> Notice that this transporting SRv6 multicast over BIER (L2.5) just like transporting SRv6 unicast over L2.
Zzh> Then, when BIER needs to go over non-BFRs and IPv6 tunnels are used for that, BIER itself can be over IPv6 tunnels (just like over any other tunnels like MPLS or even L2TP if one will). That’s the beauty of clear and independent layering.

At the beginning of the presentation Greg corrected me and stated that that after the BIERin6 independent model draft was published, that the requirement draft came about to build a set of requirements as to the “why” we need BIER to work in a non MPLS BIER in an IPv6 environment when we already have the BIER Ethernet encapsulation that fits the bill and works.

Zzh> It’s more like why we need to require IP encapsulation.

So that’s the million $$ question we are trying to solve here with the requirements draft.


As for the IPV6 6MAN questions, I was brought on board by Mike McBride as the IPv6 SME as well as multicast SME - but point being member of 6MAN for many years so a go between liaison with 6MAN related to any questions regarding following the IPV6 specification for extension header usage per RFC 8200.  Both solutions drafts had been reviewed by myself and 6MAN and no technical issues were found regarding the solutions.

Zzh> BIERv6 *can* be make to work, but at this time many of us are not convinced that it is needed, and it does have its complications (both at BIER layer itself and at flow overlay layer like with MVPN/EVPN – we can have separate discussion on that). There are many 6MAN people with different opinions – some say BIERv6 is good (from IPv6 point of view) and some others will point out its problems even just from IPv6 point of view (even when not considering BIER/MVPN).

Alvaro mentioned as far as the list of requirements that they were fairly basic but maybe needed some more meat behind it such as the “support various L2 link types” but we did not specify.  In previous versions we stated L2 agnostic and then switched to various but being vague on which L2.  Alvaro also mentioned why OAM should be a requirement.  We may want to add a sentence on justification as to why we picked BIER IPv6 requirements as required versus optional.

Zzh> I actually don’t think L2 link types is a key issue. Whatever modern L2 links that an operator wants to use, it’ll need to be supported both by IPv6 and BIER, and it is as simple as adding a codepoint for the L2 header to indicate whether the next header is IP/MPLS/BIER/whatever (again – the beauty of clear and independent layering).

We need to add some more meat in the introduction or maybe even a separate section as to what gap is being filled by non MPLS BIER in IPv6 environment using IPv6 encapsulation and encoding the BIER header versus Non MPLS BIER Ethernet.  Also maybe use the requirements section to see if a new requirement that maybe a gap that is not covered by non MPLS BIER Ethernet that can be covered by non MPLS BIER in an IPv6 environment.

Zzh> Shouldn’t we just list the requirements in the requirements section, and then evaluate different solutions using the requirements draft as guidance?

At the end of the call when we rolled through the last two drafts and went into overtime I heard the ask for call for adoption for BIERin6 independent model.

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zhang-bier-bierin6/__;!!NEt6yMaO-gk!TOnu1Jmv8QPEdOl5pPzFJK-hl8nqGL6C2I94f4HdluKFdjsXQOc5-qph9Dk4t1B7$>

I would not think we are ready to adopt any non MPLS BIER in IPV6 environment solution if we still do not have the requirements set as to the gap that is being filed and problem being solved that cannot be done today with non MPLS BIER Ethernet.

Zzh> After almost two years of requirement work, we’ve identified a set of mandatory/optional requirements. My presentation aims at showing that BIERin6 addresses all those requirements with the *existing* solution so it is good for the WG to adopt the mature solution, instead of leaving people an impression that we don’t have a solution.
Zzh> As for BIERv6, maybe after additional requirements work we’ll eventually agree that there is a need for it and then it could be adopted at that time. That should not block the progressing of BIERin6 until we find a need for BIERv6 😊
Zzh> With the above consideration, I would say the “suggested next steps” in my presentation is quite reasonable.

The flip side of the comment above is that if we are ready to adopt and we decided we can skip answering the “why” questions, so then do we need the requirements draft at all if that’s the case as we have made the decision to go with a single solution and are closing the door on any other options.  If the latter then we hang tight on any adoption of any solution and wait till the requirements draft is completed and adopted followed by moving forward with adopting any solutions.

Zzh> As I mentioned in my presentation, additional solutions can be pursued but only if they offer significant advantages. Otherwise, why should IETF/vendors/operators spend time on them? So we indeed have a “why” question – why BIERv6.

Zzh> Thanks.
Zzh> Jeffrey

Kind Regards

Gyan


--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TOnu1Jmv8QPEdOl5pPzFJK-hl8nqGL6C2I94f4HdluKFdjsXQOc5-qph9DU3E7y5$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD



Juniper Business Use Only