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

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

Hi,

One thing that I want to emphasize at the top is that existing solution (referred to as BIERin6) is not v4 specific. It is v4/v6 orthogonal.

Please see zzh2> below.

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

[External Email. Be cautious of content]


Hi Jeffrey

Please see in-line below

On Wed, Nov 18, 2020 at 11:29 AM Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,

Please see zzh> below.

From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, November 18, 2020 10:14 AM
To: Alvaro Retana <[e-mail]<mailto:[e-mail]>>; BIER WG <[e-mail]<mailto:[e-mail]>>; Greg Shepherd <[e-mail]<mailto:[e-mail]>>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Tony Przygienda <[e-mail]<mailto:[e-mail]>>; draft-ietf-bier-ipv6-requirements <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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.
     Gyan>As we worked on the revision 7 we did discuss SRv6, however we did not add to the draft as a requirement because it’s supported today with BIER Ethernet which is my point as to the “why” do we need Non MPLS BIER in IPV6 environment.  Also in IPV6 environment since SRV6 uses the IPV6 forwarding plane there should not be any issue with it working.  We can revisit if we want to add as a requirement and I think their is merit to add.

Zzh2> As I mentioned below, even if SRv6 is added to the requirement, existing solution will still work nicely with it, still with nice independent layering separation, and without the issues with draft-xie-bier-ipv6-mvpn, and actually w/o the need for procedures in that draft.
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.

     Gyan>Agreed.  That is my point why do we need IP encapsulation is the big question we need to answer in the draft.
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).

Gyan> Agreed.  We have to work on BIER IPv6 MVPN draft.

Zzh2> We actually don’t need that one with BIERin6 😊
Zzh> Notice that this transporting SRv6 multicast over BIER (L2.5) just like transporting SRv6 unicast over L2.
    Gyan> Agreed.  I don’t see any issue with SRv6 with BIERin6 independent model
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.
Gyan> Agreed
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.
 Gyan> As IPv4 is being eliminated from the core as we speak with proliferation of IPv6 in the core even before SRv6,  LDPv6 and SR-MPLSv6 the direction is softwire mesh framework v4 or v6 edge over a v6 core.  So if we are now or future it’s more like IPv6 not IP which implies IPv4 implicitly but could mean either IPv4 or IPv6.  I have a draft in BESS that eliminates IPv4 at the edge using RFC 5549 next hop encoding vendor consortium of interoperability testing so IPv4 will be soon eliminated from P core and PE edge.
https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases/__;!!NEt6yMaO-gk!WB6X0WzZxH1qWs9j87NdQcGlaSKn_5HG6ElV5zZjQxxrEKa9i-NlVPrqqnfW3sSZ$>

zzh2> Indeed the real question is why do we need IPv4/v6 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).
Gyan> I have discussed BIERv6 with many folks on 6MAN as well and the response is the solution is  sound no issues.  We can discuss on separate thread.
Zzh2> I now see new emails on the BIER list about that.
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).
 Gyan> I don’t think Alvaro was saying there was any issue but just pointing out that we did not specify which link types.  We can discuss with authors what link types we should add explicitly.
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?
 Gyan>  Greg and Tony can correct me but from what I heard is that we need to answer the “why” do we need Non MPLS BIER solution in an IPV6 environment as we already have the L2 Non MPLS BIER Ethernet solution that will work for any next header encapsulation type and will support IPv6.  So that goes for any IPv6 environment solution including BIERin6 - why do we need it.  So I and some of the other authors agree that is missing so we need to add verbiage around that which is separate from the requirements section.
Zzh2> The real questions are: 1) why do we need IPv6 encapsulation (BFIR->BFER or between adjacent BFRs) 2) Even if you do, where do you put the BIER header. 1) is a requirement question, and 2) is a solution question.
Zzh2> With BIERin6, 2) has the clean, simple layering property: if you do need BFIR->BFER IPv6 encapsulation, IPv6 is the BIER payload; if you need BFR->BFR encapsulation (either directly or indirectly connected), BIER is the IPV6 payload.
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.

     Gyan> Given what Greg and Tony stated as far as the requirements draft as what is missing related to the “why” we need any IPv6 environment solution I think “any” means any which include BIERin6.  We may need some clarification from the chairs on this.

Zzh2> My understanding is the question is “why we need IPv6 encapsulation” (especially BFIR->BFER). BIERin6 does not require BFIR->BFER encapsulation, but it works nicely with that.
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 😊

Gyan> My POV is the requirements draft applies to both solutions on the table.  So if we have not answered the why how can we have any solution let alone adopt any.  It does sound like a setback but it could easily be a quick silver lining that immediately moves both drafts to WG adoption.  I think if we update the introduction section to answer the “why” question and then maybe a round of cleanup of the requirements section I think we can move the ball forward on the requirements draft and that would allow both solutions drafts to adopted.

My take is I don’t think the BIERin6 is exempt from having to meet the requirements laid out in the requirements draft which includes “why” have we spent 2 years developing a solution which we don’t even know why we need it.  I would say both solutions are in the same boat.

Zzh2> The requirements draft certainly applies to both solutions. My points are: 1) so far all the requirements listed in the draft are satisfied by BIERin6 2) The main question from the chairs is “why we need IPv6 encapsulation”
Zzh2> As I mentioned above, BIERin6 does not require IPv6 encapsulation, though it can nicely work with IPv6 encapsulation.
Zzh2> As a result, I don’t see why BIERin6 needs to be held back – why should we hold back BIERin6 until you find a requirement that warrants BIERv6? If that requirement does come up, BIERv6 can be adopted at that time.
Zzh2> BTW, my understanding is that if BIERv6 were not brought up, we would not have needed the requirements draft work 😊
Zzh> With the above consideration, I would say the “suggested next steps” in my presentation is quite reasonable.
Gyan> Let’s have the chairs and AD chime in on this thread.

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.
 Gyan> Agreed.  But I still think we have the which comes first the chicken or the egg.  The chicken being BIERin6 or the egg being finalizing the requirements draft.  I am not trying to hold up BIERin6 from WG adoption but that is my take from the chairs.
Zzh2> To rephrase, the why question for the requirements draft is “why IPv6 encapsulation”, and that answers “why BIERv6” question. Again, BIERin6 works nicely with IPv6 encapsulation as well.
Zzh2> Jeffrey
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<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!WB6X0WzZxH1qWs9j87NdQcGlaSKn_5HG6ElV5zZjQxxrEKa9i-NlVPrqqq6twCEV$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!WB6X0WzZxH1qWs9j87NdQcGlaSKn_5HG6ElV5zZjQxxrEKa9i-NlVPrqqq6twCEV$>



Juniper Business Use Only
--

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

Gyan Mishra

Network Solutions Architect

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



Juniper Business Use Only