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

[Greg Shepherd <[e-mail]>]

GS - Inline:

On Thu, Nov 19, 2020 at 3:26 AM Jeffrey (Zhaohui) Zhang <[e-mail]>
wrote:

> 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]> wrote:
>
> 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.
>
>      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.
>
>
GS - See my previous email response. The reqs draft came about after the
BIERv6 draft was published, not after BIERin6. The WG had no issues with
BIERin6 draft, other than limited WG interest at that time so it sat on
ice. When BIERv6 draft was published, many concerns were raised, the
conversations began looping in confusing miss-information twisters:
Transitional mechanism? Not transitional? "Integrated" into the v6 fwd
plane?, etc.. So it was clear we needed a document to follow to ensure we
are all hearing and agreeing to the same information.


> 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.
>
>
GS - ^^^This. Thanks Jeffrey.


> 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.
>

GS - ^^^And this. As I said before, the WG had NO issues with BIERin6. The
reqs draft came about as a means to document the WGs direction in this
space in the light of BIERv6.

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”
>

GS - Yes, this is the original and lingering question.


> 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.
>
>
GS - Curious to hear your thoughts now that I've added clarity as to "what
the chairs said", and to the overall history of the process.

Thanks,
Greg


> 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: 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: 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
>