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

From: Gyan Mishra <[email-masked]>
Date: Wed, 18 Nov 2020 10:14:20 -0500

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.

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.

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.

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.

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.

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/

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.

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.

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 18 Nov 2020 16:29:50 +0000

Hi Gyan,

Please see zzh> below.

From: Gyan Mishra <[email-masked]>
Sent: Wednesday, November 18, 2020 10:14 AM
To: Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; Greg Shepherd <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>; [email-masked] <[email-masked]>
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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 18 Nov 2020 17:18:36 -0500

Hi Jeffrey

Please see in-line below

On Wed, Nov 18, 2020 at 11:29 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi Gyan,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Wednesday, November 18, 2020 10:14 AM
> *To:* Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>;
> Greg Shepherd <[email-masked]>; Jeffrey (Zhaohui) Zhang <
> [email-masked]>; Tony Przygienda <[email-masked]>;
> draft-ietf-bier-ipv6-requirements <
> [email-masked]>; [email-masked] <
> [email-masked]>
> *Subject:* draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> All
>
>
>
> 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
> 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.

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

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

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

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

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

> 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.
>
> Zzh> Thanks.
>
> Zzh> Jeffrey
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> --
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> <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://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

*Gyan Mishra*

---

From: <[email-masked]>
Date: Thu, 19 Nov 2020 11:09:04 +0800 (CST)

Hi Gyan,

We can't come to the conclusion that there is no technical issues within 6MAN regarding the solutions you mentioned. I raised a thread (Extension Header processing rules) in 6MAN and want to hear suggestions from more 6MAN experts, and Bob, Tom gava fair advice.

Yes, in theory, you can do anything with DOH (in your case you want to let DOH have a behavior like Routing Header). But, the fact is that specific Extension Header is defined for specifc purpose. 

In your solution that you mentioned, you want to:

1) Update DA again and again by the information get from DOH before the packet reach the final destination.

2) When DOH is finished to be processed at the node that matched DA, the Next Header is not continued to be processed.

I don't see the above two strange features in the existing Options defined for DOH. See https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

0x04	00	0	00100	Tunnel Encapsulation Limit	[RFC2473]

0xC9	11	0	01001	Home Address	[RFC6275]

0x8B	10	0	01011	ILNP Nonce	[RFC6744]

0x8C	10	0	01100	Line-Identification Option	[RFC6788]

0x0F	00	0	01111	Performance and Diagnostic Metrics (PDM)	[RFC8250]

0x11	00	0	10001	IOAM 	[draft-ietf-ippm-ioam-ipv6-options]

0x31	00	1	10001	IOAM    [draft-ietf-ippm-ioam-ipv6-options]

There are other technical issues of course.

For example, using SRv6 SID in the DA field of BIER IPv6 packet to indicate there are BIER information Option in DOH is superfluous. IMO, Option Type itself can do that, and there maybe more options in single DOH. So far I have not seen an SRv6 SID is used to indicate the decapsulation things that Next Header field can be done, please refer to any endpoint behaviors defined in SRv6 PGM. Please also note that in RFC8754 for an IPv6 packet with SRH, it is possible a normal IPv6 address is contained in DA when Segment Left is 0. That means the DA itself can not give you any indication to decapsulate the packet. Depending on Next Header is standard behavior.

BTW, please take care ICMP issues related with SA.

Regards,

PSF

原始邮件

发件人：GyanMishra
收件人：Alvaro Retana;BIER WG;Greg Shepherd;Jeffrey (Zhaohui) Zhang;Tony Przygienda;draft-ietf-bier-ipv6-requirements;张征00007940;
日 期 ：2020年11月18日 23:14
主 题 ：[Bier] draft-ietf-bier-ipv6-requirements-09

_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

All

Kind Regards 

Gyan

-- 

Gyan Mishra

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

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 18 Nov 2020 19:50:38 -0800

On November 19, 2020 at 3:18:58 AM, Gyan Mishra wrote:

Hi!

Just a couple of comments.

> On Wed, Nov 18, 2020 at 11:29 AM Jeffrey (Zhaohui) Zhang wrote:
..
> > From: Gyan Mishra
...
> > > 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.
> >
> 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.

<individual hat on>

It was Loa, not me, who raised the point about the L2 requirement
being vague.  I do agree with him.  I also agree with Jeffrey on his
point that "modern L2 links that an operator wants to use, it’ll need
to be supported".  To me, this then becomes another general
requirement -- unless there's a special reason to add or exclude
something.

I did say that the mandatory requirements are general and broad.  For
example, "support the BIER architecture" is obvious, and I assume both
solutions do.  BTW, "deployments with BIER-incapable routers" is also
covered in rfc8279.

My comment about OAM was along the lines of the fact that there is no
standard BIER OAM mechanism defined.  It seems like a stretch to
require BIER functionality that has not been defined.  A better
approach might be to explain the required functionality (for example,
continuity, liveliness, etc.).

...
> Gyan> Let’s have the chairs and AD chime in on this thread.

<AD hat on.>

As I mentioned on the call, my opinions on this thread are as an
individual.  The Chairs are more than capable of providing direction
and don't need me for that.

Thanks!

Alvaro.

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 18 Nov 2020 23:08:33 -0800

Quick correction here as to OAM. OAM is worked on and multiple quite
extensive & well-written drafts dealing with OAM aspects are adopted/in
flight since quite a while (I count 4 adopted & 1 individual). BIER has
been specifically architected with multicast OAM in mind which is
non-trivial such as MTU discovery (we have 2 drafts for a good reason &
discussion is pending) and dealing with OAM when we're dealing with mp2mp
trees (which BIER basically is or can be used at). One of the reasons BIER
found interest in the set of people that need/like it is that they were
looking for very tight OAM guarantees in orders of microseconds and that
without highly specific hardware designed for it is very difficult (and
packet format, that's why OAM is first order citizen in BIER in terms of
bits provided e.g. for marking purposes and can be found in a very specific
offset. to support the OAM desired HW has to process and generate
sub-microseconds trains.

As far as I saw there was not much on the radar in terms of anything
comparable in SRv6 OAM work beside "SID-ping" if the intention is to rely
on SRv6 to deal with that problem. But of course I may have missed some
draft. Even if they work on unicast OAM I may express my profound doubts
there will be interest or focus to solve OAM for SRv6 becoming a L3
multicast transport with the type of OAM BIER needs on top.

As to desired OAM, I think we have an OAM requirements draft adopted with
quite a list of industry authors since quite a bit. this draft has WG
consensus and has to be satisfied.

https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/?include_text=1

-- tony

On Wed, Nov 18, 2020 at 7:50 PM Alvaro Retana <[email-masked]>
wrote:

> pointing

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 19 Nov 2020 11:26:31 +0000

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 <[email-masked]>
Sent: Wednesday, November 18, 2020 5:19 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Greg Shepherd <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Hi Jeffrey

Please see in-line below

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

Please see zzh> below.

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

All

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

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.

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.

     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.

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

--

Gyan Mishra

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

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

Gyan Mishra

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

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 19 Nov 2020 09:22:03 -0800

GS - inline:

> guidance this morning to help move the ball forward with the requirements

Thank you for your help.

> Ethernet ether type 0xAB37.

GS - No, the BIER header is NOT 'encoded' in MPLS. MPLS encapsulates the
BIER packet. Yes, the outer label included BIER specific information
(Set-ID) with the intent of streamlining the forwarding process but without
creating a dependency. We mirrored the format for Eth encap to ensure a
single header format for the BIER architecture standard. It's important to
mention there that the process to get to this point involved a 3-day
design-team meeting where we worked hard, transparently and together and
managed to conclude with a solution which resolved any conflict, satisfied
everyone's concerns, and resulted in a clean, consistent message from a
Working Group that was working under the 'experimental' banner. We moved
from 'experimental' to standards track by listening to all the reasons we
were started out as 'experimental' in the first place - ie This is the
forwarding plane and will require new HW so the work from the WG must
justify a new forwarding model and produce clear standards to follow.

> become the end all be all “core transport” mechanism for all operators.
>

GS - This is an opinion and not a technical argument. BTW, it is MY opinion
that the largest early adopters for BIER will be financial networks, and
more specifically financial trading floors. These networks are dedicated,
high-speed, multipoint networks that will never adopt SRv6. Remember the
IETF is to create standards that work best for everyone, not just to solve
our individual network issues or vision.

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

GS - Just for clarity, RFC8296 works today regardless of any
perceived transport wars. That's because a proper layered architecture
avoids layer dependencies.

> already have the BIER Ethernet encapsulation that fits the bill and works.

GS - Not exactly... Let me clarify:
  BIERin6 first published in Oct 2017. I think the primary interest at the
time was Homenet. The WG had no issues with the solution, but then neither
had many members stepping up to help. Our AD's (and through extension the
IAB) ingrained in us the need to remain diligent in the publication of our
standards and only progress work that remained consistent with our existing
work and showed community support. The first was true, the second was a
little slight at the time.

  April 2018 - the BIER Encap (misnomer) draft was published. It was
pointed out from the beginning that there is a stark difference between
encap and encode and that the WG has already published standards for
encode. So the question was asked, why do you need a new encoding and
encap. The answer given at the time was that there was a need to address
non-BIER routers in the network and that this solution would be
transitional. The WG pushed back that ANY transition mechanisms MUST NOT
require HW changes. We also heard things like:
"integrated into IPv6" - not true, it's merely BIER information encoded
into extension headers. Operationally this is identical to BIERin6 encap,
except that the former would require new HW, something our AD's made clear
needs to be justified before progressing.
"fast-path" - not true.
I/We continued to ask questions trying to understand what benefits could be
implied by encoding the BIER header into an IPv6 extension header rather
than to just encap the BIER packet? And ultimately what is to be
accomplished with any new encap now that we have RFC8296? The WG decided we
needed a problem statement and requirements draft to guide any work in this
space.

The reqs draft was heavily weighted by BIEREncode draft authors and showed
significant effort to direct the conversation. The WG was largely silent on
any support either way. Mike came to me frustrated that nobody is stepping
up to help. My reply was that if the WG doesn't show interest in the work,
maybe that's your answer. Since then, more authors have been added.

> So that’s the million $$ question we are trying to solve here with the

GS - Yes, but redefined as per my explanation above.

> no technical issues were found regarding the solutions.

GS - Thank you.

> into overtime I heard the ask for call for adoption for BIERin6 independent

GS - Both v6 draft presentations asked for adoption. One of them had
technical arguments for doing so. The other was list of grievances.

> with non MPLS BIER Ethernet.

GS - Agree.

> moving forward with adopting any solutions.

GS - Agree. And my suggestion for new authors on the reqs draft still
stands. I'm not demanding, I'm suggesting, based on the document's history.
Your presentation of the history of the draft made it clear that there has
been little direction, less clarity, and potentially an excessive amount of
motivation to justify one solution over the other, leaving us with the
mushy reqs draft we have today. Let's get this draft right, then we will
have the guidance to address any potential solutions.

Thanks,
Greg

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 19 Nov 2020 09:39:26 -0800

GS - Inline:

On Thu, Nov 19, 2020 at 3:26 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
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.
>
>
>
> *Sent:* Wednesday, November 18, 2020 5:19 PM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Cc:* Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>;
> [email-masked] <[email-masked]>; Greg Shepherd <
> [email-masked]>; Tony Przygienda <[email-masked]>;
> [email-masked]>
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> On Wed, Nov 18, 2020 at 11:29 AM Jeffrey (Zhaohui) Zhang <
> [email-masked]> wrote:
>
> Hi Gyan,
>
>
>
> Please see zzh> below.
>
>
>
> 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.
>
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.

> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases/__;!!NEt6yMaO-gk!WB6X0WzZxH1qWs9j87NdQcGlaSKn_5HG6ElV5zZjQxxrEKa9i-NlVPrqqnfW3sSZ$>
>
>
>
> 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.
>
>      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
> 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.

> 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 😊
>
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
>
>
>
>
>
> --
>
> *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$>
>
>
>
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!WB6X0WzZxH1qWs9j87NdQcGlaSKn_5HG6ElV5zZjQxxrEKa9i-NlVPrqqisVX69W$>
>
> *Gyan Mishra*
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 19 Nov 2020 21:35:40 -0800

Well, I’m glad that the work on requirements draft, albeit as product found
wanting in AD’s assessment, has led to clarification of the crucial
questions that e'one seems to agree need to be asked.

It surprised me then mildly that my co-chair had to explicitly lay out the
semantics of what was a clear direction spelled out during the meeting but
that’s all well to get e’one better in sync I guess. Needless to say I am
sharing his assessment and questions put to the room entirely.

Some things that I think need explicit spelling out IMO after the last few
meetings (since I’m not sure e’one in the process internalized that) is
that WG is not here to tell people they cannot work on something whatever
the perception seems to be, IETF doesn’t work that way. People go sideways
and build stuff based on what we publish/develop in open source and for
their customers in all kind of ways which may be neither fitting into an
architecture, consensus or interest of a WG all the time. And that’s
wonderful and more power to them, RFCs are free to download and they are
just RFCs, they are not stone tablets brought from the mountain. However,
and that's a big however, _if_ a work is looking for WG adoption and
ultimately RFC status, the IETF process kicks in and the process has been
here and well debugged over 30 years and that’s why Internet was built IME.
The process is unusual in the way that it resists pretty well pressure
based on non-technical claims, exceedingly poor architectural choices,
chair shopping, padding of communication channels with “I participated only
once to send a +1 to a list”, ad-hominem attacks and similar shenanigans
that have been all tried over and over again. In the same vein the process
tends to weigh based on reputation of “who said what in which context”';
such reputation being built on community service and sound work over many
years. And sometimes hard calls are made based on rough consensus called by
people that are here to steer stuff and nudge it along the way. Sure, it’s
easy to standardize and build “something”, it’s very hard to keep it going
operationally @ Internet scale for 20 years and lots of those lessons are
unfortunately scar tissue not easily transferred except at level of
RFC1925. Last point to emphasize is that BIER is not the average set of
RFCs, we have been handed the permission to go into the hourglass of the
Internet, something that happens every 15 years or so. The stuff we deliver
is as fundamental as MPLS or IP forwarding plane and as PS has to meet
toughest architectural standards to prevent a melt-down of non-orthogonal,
under’spec’ed solutions leading to poor operational properties @ scale and
non-interoperable solutions which long-term serves no'one well that relies
on IP technology to support high quality infrastructure @ scale.

--- tony

On Thu, Nov 19, 2020 at 9:39 AM Greg Shepherd <[email-masked]> wrote:

> GS - Inline:
>
> On Thu, Nov 19, 2020 at 3:26 AM Jeffrey (Zhaohui) Zhang <
>>      Gyan>Agreed.  That is my point why do we need IP encapsulation is
>> the big question we need to answer in the draft.
>>
>>  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.
>>
>>
>>
>>  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
>> 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.
>>
>>
>>
>> Zzh> After almost two years of requirement work, we’ve identified a set
>> of mandatory/optional requirements. My presentation aims at showing that
>> Zzh2> My understanding is the question is “why we need IPv6
>> encapsulation” (especially BFIR->BFER). BIERin6 does not
>>
>> 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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Nov 2020 15:00:19 -0500

Hi Greg

In-line

Thank you again both you and Tony and Alvaro for all your guidance to help
right the ship!!

I will by “first round” when we meet in person — some day!!👍😁- maybe even
second and third - or the night is on me if we can get this behind us. 😀

Thanks

>> guidance this morning to help move the ball forward with the requirements

     Gyan> Welcome

> justify a new forwarding model and produce clear standards to follow.

   Gyan> Thank you for clarification on BIER MPLS and important history on
the BIER encapsulation types and how they came about and the evolution from
Experimental to Standards Track.  I can see the simplicity single header
format beauty behind the BIER architecture.

> GS - This is an opinion and not a technical argument. BTW, it is MY
> opinion that the largest early adopters for BIER will be financial
> networks, and more specifically financial trading floors. These networks
> are dedicated, high-speed, multipoint networks that will never adopt SRv6.
> Remember the IETF is to create standards that work best for everyone, not
> just to solve our individual network issues or vision.
>

    Gyan> Understood.

> avoids layer dependencies.
     Gyan> Understood.  The BIER encapsulations types MPLS and Non MPLS
defined in RFC 8296 works well with the RFC 8279 BIER 3 layer architecture,
underlay, BIER layer, overlay which are independent of each other.  Makes
sense.

> I/We continued to ask questions trying to understand what benefits could
> be implied by encoding the BIER header into an IPv6 extension header rather

    Gyan> Thank you for the important clarification on history of how
things transpired and how the requirements draft came about.  As well as
history of BIERin6 and BIERv6.  Makes perfect sense as what triggered the
requirements draft was the second solution BIERv6.

Operationally as you stated as well as from the BIER layering perspective 2
out of the 3 layers ar identical as both have underlay and overlay and thus
are mirrored on the encapsulation in the layering.
As you mentioned the stark difference comes is the “BIER” layer where with
BIERin6 it fits right in the middle of the inner and outer layer “encap”
where with BIERv6 the additional encoding of the BIER header was the tricky
part for sure.

We leveraged following verbatim the IPv6 specification RFC 8200 to encode
the BIER header in the DOH extended header for en route hop by hop BIFT
processing very similar to hbh header processing.

So there being the stark difference where BIERin6 was “encap” based and
BIERv6 was “encap” + additional “encode” based, thus the pushback as to
giving concrete reasoning for having a solution that requires the
additional “encode”.  Agreed.

Our answer as you stated has been that BIERv6 solution would be a
transitional solution to accommodate “Non BFR” routers and that is still
the case.  As stated with the BIERv6 integrated solution , the key problem
that has to be solved to make that solution viable is where to put the BIER
header.

As “encap” was not an option as that would literally make BIERv6 identical
to BIERin6 - thus the MAJOR challenge as to where to put the BIER header as
there really is no other place other then in an extension header.  Another
option that is still another viable option is picking a different header
such as hbh to encode the BIER header.  We chose DOH as it had the options
flag value option 3 for en route so at the time it made sense to go with
DOH.  With many drafts looking at hbh for performance measurements in-situ
hbh processing in the fast path, it is possible that hbh could still be a
viable alternative.

One other significant difference between BIERin6 and BIERv6 is that BIERin6
is to some degree a “pseudo” IPV6 environment solution as L2 links direct
Non MPLS Ethernet encapsulation can be used to transport BIER packets.  So
this is HUGE has far as stark difference and major advantage of BIERin6
over BIERv6.

So with BIERin6 in an IPv6 environment, the IPv6 tunnel encapsulation and
decapsulation for HBH BIFT processing only needs to be done in case of “Non
BFR” routers present in “transitionary method”.

“Between two BFRs,either a L2 link can be used directly or any tunnel
(IPv6 or not) can be used for BIER transport.”

    One example of this model is defined in [I-D.zhang-bier-bierin6
<https://tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-08#ref-I-D.zhang-bier-bierin6>],

   where the BIER header and the payload following it are L2 payload
   when feasible (e.g.  when two BFRs are directly connected) or IPv6
   payload when IPv6 transport is needed/desired (e.g. when two BFRs are
   not directly connected).  This is indicated by either a 0xAB37
   Ethertype allocated to BIER or a new IPv6 Next-Header value to be
   allocated by IANA.

This does give BIERin6 significant advantage over BIERv6 that in a IPV6
environment as BIERin6 can leverage existing RFC 8296 encapsulation non
MPLS BIER Ethernet solution already in place today

So to state differently how BIERin6 is envisioned as a “pseudo” IPv6
encapsulation solution is that in Green field deployments we would only use
L2 to connect BFRs via non MPLS BIER Ethernet ether type Oxab37 which then
this would be case and point that you don’t need the BIERin6 solution to
accomplish as that exists in RFC 8296.  Was this done on purpose- I think
so as why reinvent the wheel so to speak.  Makes sense to me.

BIERin6 using IPv6 encapsulation and decapsualation technique for BIER
header transport would only be used in transition where non BFRs exist to
tunnel unicast over for backwards compatibility for existing old hardware.
Once all brown field Non BFR routers are upgraded in essence we are back to
the original RFC 8296 non MPLS BIER Ethernet solution.

So as we don’t want to reinvent the wheel as we already have a solution for
IPV6 environment, these two solutions are transitional “interim” stop gap
measures bandaid if you will to get to the end state solution we already
have today for IPV6 environments.

So I think it’s fair to state and please let me know if my extrapolation is
way off base!

As I stated earlier that in BIERin6 solution makes this crystal clear that
we already have a solution for transporting BIER packets in a Non MPLS BIER
IPV6 environment using RFC 8296 non MPLS BIER Ethernet ether type 0xab37.

As the big million $$ - why do we need another solution for IPv6
environment-  the answer is and correct me if I am off base = “we don’t”

Both BIERin6 “encap” solution and BIERv6 “encap” + “encode” solution would
only be used for brown field transitional sense and never was meant to be a
long term - shall we say alternative solution to carry BIER packets.  Point
being is we already have a solution so why reinvent the wheel.

As far as IPV6 extended header usage and processing see below:

With graconian routers of the past with extended header processing and on
6man and v6ops there have been many drafts written for best practices to
not drop extended headers with fear of dos attack on the control plane but
impacting legitimate customer traffic that used extended headers. Modern
router processing of extension headers has advanced quite significantly
over the past 20 years being able to process hbh as well as doh en route
hop by hop at line rate in the forwarding plane fast path.  No new hardware.

>> no technical issues were found regarding the solutions.

    Gyan> Welcome

> technical arguments for doing so. The other was list of grievances.

     Gyan> Understood and duly noted

>> with non MPLS BIER Ethernet.

    Gyan> Agreed.  So to reiterate once we complete the requirements draft
and then if both fit the Bill of the requirements draft, we can ask for
Adoption of both drafts at once.

> have the guidance to address any potential solutions.

    Gyan> Agreed on all points.  I will captain and right the ship and get
out of muddy waters to a crystal clear draft that can provide concrete
guidance on a solution.   Please see my points above on the transitional
aspects of this solution and if in the end state we would use the existing
RFC 8296 Non MPLS BIER Ethernet in an IPV6 environment then that provides a
lot of clarity to the team as to direction.  So that million $$ question
goes away in essence as we have already answered our own question due to
transitional nature of this IPV6 environment solution we are developing now
with these two “non end state” transitional only solutions.

>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> --

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 21 Nov 2020 18:45:17 +0000

About the following:

GS - Agree.

    Gyan> Agreed.  So to reiterate once we complete the requirements draft and then if both fit the Bill of the requirements draft, we can ask for Adoption of both drafts at once.

Now it’s clear what the chair was requesting for the requirements draft. Quote from Greg’s reply to the other email:

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

So the requirements draft will discuss why IPv6 encapsulation is needed. As I mentioned in my previous email, even if there is a requirement for IPv6 encapsulation, BIERin6 works nicely with it, and works better with a clean layering architecture.

As such, we believe BIERin6 is already ready for adoption – though we’ll put out a revision to evaluate against the requirements draft. It is not reasonable or fair to delay the adoption of this one any further until the requirements draft justifies the other solution.

Thanks.
Jeffrey

From: Gyan Mishra <[email-masked]>
Sent: Friday, November 20, 2020 3:00 PM
To: [email-masked]
Cc: Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Hi Greg

In-line

Thank you again both you and Tony and Alvaro for all your guidance to help right the ship!!

I will by “first round” when we meet in person — some day!!👍😁- maybe even second and third - or the night is on me if we can get this behind us. 😀

Thanks
On Thu, Nov 19, 2020 at 12:22 PM Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
GS - inline:

On Wed, Nov 18, 2020 at 7:14 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:
All

Thank you for your help.

     Gyan> Welcome

GS - No, the BIER header is NOT 'encoded' in MPLS. MPLS encapsulates the BIER packet. Yes, the outer label included BIER specific information (Set-ID) with the intent of streamlining the forwarding process but without creating a dependency. We mirrored the format for Eth encap to ensure a single header format for the BIER architecture standard. It's important to mention there that the process to get to this point involved a 3-day design-team meeting where we worked hard, transparently and together and managed to conclude with a solution which resolved any conflict, satisfied everyone's concerns, and resulted in a clean, consistent message from a Working Group that was working under the 'experimental' banner. We moved from 'experimental' to standards track by listening to all the reasons we were started out as 'experimental' in the first place - ie This is the forwarding plane and will require new HW so the work from the WG must justify a new forwarding model and produce clear standards to follow.

   Gyan> Thank you for clarification on BIER MPLS and important history on the BIER encapsulation types and how they came about and the evolution from Experimental to Standards Track.  I can see the simplicity single header format beauty behind the BIER architecture.

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.

GS - This is an opinion and not a technical argument. BTW, it is MY opinion that the largest early adopters for BIER will be financial networks, and more specifically financial trading floors. These networks are dedicated, high-speed, multipoint networks that will never adopt SRv6. Remember the IETF is to create standards that work best for everyone, not just to solve our individual network issues or vision.

    Gyan> Understood.

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.

GS - Just for clarity, RFC8296 works today regardless of any perceived transport wars. That's because a proper layered architecture avoids layer dependencies.

     Gyan> Understood.  The BIER encapsulations types MPLS and Non MPLS defined in RFC 8296 works well with the RFC 8279 BIER 3 layer architecture, underlay, BIER layer, overlay which are independent of each other.  Makes sense.

GS - Not exactly... Let me clarify:
  BIERin6 first published in Oct 2017. I think the primary interest at the time was Homenet. The WG had no issues with the solution, but then neither had many members stepping up to help. Our AD's (and through extension the IAB) ingrained in us the need to remain diligent in the publication of our standards and only progress work that remained consistent with our existing work and showed community support. The first was true, the second was a little slight at the time.

  April 2018 - the BIER Encap (misnomer) draft was published. It was pointed out from the beginning that there is a stark difference between encap and encode and that the WG has already published standards for encode. So the question was asked, why do you need a new encoding and encap. The answer given at the time was that there was a need to address non-BIER routers in the network and that this solution would be transitional. The WG pushed back that ANY transition mechanisms MUST NOT require HW changes. We also heard things like:
"integrated into IPv6" - not true, it's merely BIER information encoded into extension headers. Operationally this is identical to BIERin6 encap, except that the former would require new HW, something our AD's made clear needs to be justified before progressing.
"fast-path" - not true.
I/We continued to ask questions trying to understand what benefits could be implied by encoding the BIER header into an IPv6 extension header rather than to just encap the BIER packet? And ultimately what is to be accomplished with any new encap now that we have RFC8296? The WG decided we needed a problem statement and requirements draft to guide any work in this space.

The reqs draft was heavily weighted by BIEREncode draft authors and showed significant effort to direct the conversation. The WG was largely silent on any support either way. Mike came to me frustrated that nobody is stepping up to help. My reply was that if the WG doesn't show interest in the work, maybe that's your answer. Since then, more authors have been added.

    Gyan> Thank you for the important clarification on history of how things transpired and how the requirements draft came about.  As well as history of BIERin6 and BIERv6.  Makes perfect sense as what triggered the requirements draft was the second solution BIERv6.

Operationally as you stated as well as from the BIER layering perspective 2 out of the 3 layers ar identical as both have underlay and overlay and thus are mirrored on the encapsulation in the layering.
As you mentioned the stark difference comes is the “BIER” layer where with BIERin6 it fits right in the middle of the inner and outer layer “encap” where with BIERv6 the additional encoding of the BIER header was the tricky part for sure.

We leveraged following verbatim the IPv6 specification RFC 8200 to encode the BIER header in the DOH extended header for en route hop by hop BIFT processing very similar to hbh header processing.

So there being the stark difference where BIERin6 was “encap” based and BIERv6 was “encap” + additional “encode” based, thus the pushback as to giving concrete reasoning for having a solution that requires the additional “encode”.  Agreed.

Our answer as you stated has been that BIERv6 solution would be a transitional solution to accommodate “Non BFR” routers and that is still the case.  As stated with the BIERv6 integrated solution , the key problem that has to be solved to make that solution viable is where to put the BIER header.

As “encap” was not an option as that would literally make BIERv6 identical to BIERin6 - thus the MAJOR challenge as to where to put the BIER header as there really is no other place other then in an extension header.  Another option that is still another viable option is picking a different header such as hbh to encode the BIER header.  We chose DOH as it had the options flag value option 3 for en route so at the time it made sense to go with DOH.  With many drafts looking at hbh for performance measurements in-situ hbh processing in the fast path, it is possible that hbh could still be a viable alternative.

One other significant difference between BIERin6 and BIERv6 is that BIERin6 is to some degree a “pseudo” IPV6 environment solution as L2 links direct Non MPLS Ethernet encapsulation can be used to transport BIER packets.  So this is HUGE has far as stark difference and major advantage of BIERin6 over BIERv6.

So with BIERin6 in an IPv6 environment, the IPv6 tunnel encapsulation and decapsulation for HBH BIFT processing only needs to be done in case of “Non BFR” routers present in “transitionary method”.

“Between two BFRs,either a L2 link can be used directly or any tunnel (IPv6 or not) can be used for BIER transport.”

    One example of this model is defined in [I-D.zhang-bier-bierin6<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-08*ref-I-D.zhang-bier-bierin6__;Iw!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guGv38Vu_$>],

   allocated by IANA.

This does give BIERin6 significant advantage over BIERv6 that in a IPV6 environment as BIERin6 can leverage existing RFC 8296 encapsulation non MPLS BIER Ethernet solution already in place today

So to state differently how BIERin6 is envisioned as a “pseudo” IPv6 encapsulation solution is that in Green field deployments we would only use L2 to connect BFRs via non MPLS BIER Ethernet ether type Oxab37 which then this would be case and point that you don’t need the BIERin6 solution to accomplish as that exists in RFC 8296.  Was this done on purpose- I think so as why reinvent the wheel so to speak.  Makes sense to me.

BIERin6 using IPv6 encapsulation and decapsualation technique for BIER header transport would only be used in transition where non BFRs exist to tunnel unicast over for backwards compatibility for existing old hardware.  Once all brown field Non BFR routers are upgraded in essence we are back to the original RFC 8296 non MPLS BIER Ethernet solution.

So as we don’t want to reinvent the wheel as we already have a solution for IPV6 environment, these two solutions are transitional “interim” stop gap measures bandaid if you will to get to the end state solution we already have today for IPV6 environments.

So I think it’s fair to state and please let me know if my extrapolation is way off base!

As I stated earlier that in BIERin6 solution makes this crystal clear that we already have a solution for transporting BIER packets in a Non MPLS BIER IPV6 environment using RFC 8296 non MPLS BIER Ethernet ether type 0xab37.

As the big million $$ - why do we need another solution for IPv6 environment-  the answer is and correct me if I am off base = “we don’t”

Both BIERin6 “encap” solution and BIERv6 “encap” + “encode” solution would only be used for brown field transitional sense and never was meant to be a long term - shall we say alternative solution to carry BIER packets.  Point being is we already have a solution so why reinvent the wheel.

With graconian routers of the past with extended header processing and on 6man and v6ops there have been many drafts written for best practices to not drop extended headers with fear of dos attack on the control plane but impacting legitimate customer traffic that used extended headers. Modern router processing of extension headers has advanced quite significantly over the past 20 years being able to process hbh as well as doh en route hop by hop at line rate in the forwarding plane fast path.  No new hardware.

GS - Thank you.

    Gyan> Welcome

GS - Both v6 draft presentations asked for adoption. One of them had technical arguments for doing so. The other was list of grievances.

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

GS - Agree.

    Gyan> Agreed.  So to reiterate once we complete the requirements draft and then if both fit the Bill of the requirements draft, we can ask for Adoption of both drafts at once.

GS - Agree. And my suggestion for new authors on the reqs draft still stands. I'm not demanding, I'm suggesting, based on the document's history. Your presentation of the history of the draft made it clear that there has been little direction, less clarity, and potentially an excessive amount of motivation to justify one solution over the other, leaving us with the mushy reqs draft we have today. Let's get this draft right, then we will have the guidance to address any potential solutions.

    Gyan> Agreed on all points.  I will captain and right the ship and get out of muddy waters to a crystal clear draft that can provide concrete guidance on a solution.   Please see my points above on the transitional aspects of this solution and if in the end state we would use the existing RFC 8296 Non MPLS BIER Ethernet in an IPV6 environment then that provides a lot of clarity to the team as to direction.  So that million $$ question goes away in essence as we have already answered our own question due to transitional nature of this IPV6 environment solution we are developing now with these two “non end state” transitional only solutions.

Thanks,
Greg

Kind Regards

Gyan

--

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

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guKR8EuJa$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guKR8EuJa$>

--

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

Gyan Mishra

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 21 Nov 2020 20:45:08 -0500

On Sat, Nov 21, 2020 at 1:45 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Now it’s clear what the chair was requesting for the requirements draft.
> Quote from Greg’s reply to the other email:
>
> Gyan>Agreed
>
> So the requirements draft will discuss why IPv6 encapsulation is needed.
> As I mentioned in my previous email, even if there is a requirement for
> IPv6 encapsulation, BIERin6 works nicely with it, and works better with a
> clean layering architecture.
>
>  Gyan> Understood.  As I stated explicitly in the response to Greg above.
> What are your thoughts on what I stated that BIERin6 solution- if you
> remove the L2 links concept as that is Non MPLS BIER Ethernet RFC 8296
> (BIERin6 L2) which already exists today and would be used for Green field
> IPv6 environments so imagine then the BIERin6 solution without the L2 do
> you agree that this solution as well as BIERv6 solutions in an IPV6
> environment is strictly only for transitional brown field deployments to
> tunnel unicast over “non BFR capable” routers?
>
    Or do you think that although we already have the RFC 8286 Non MPLS
BIER Ethernet solution for IPV6 environments the goal is to have additional
alternatives for operators for IPV6 environments that are L2 ethernet and
/or other non Ethernet link layer which would be a remaining gap as to why
an IPV6 encapsulation is needed.  I guess I  am somewhat answering that why
question partially but let’s say a carrier packet switched network that
used GMPLS / MPLS-TP but a new architecture non MPLS based that lives in an
IPV6 environment- SRv6 a candidate but prove how L2 would not work and
these two proposed solutions fill the gap.

As I stated if BIERv6 and BIERin6 are really slated to be temporary until
all brown field non BFR capable routers are upgraded then we don’t need to
answer the questions as this is a temporary stop gap measure.

> As such, we believe BIERin6 is already ready for adoption – though we’ll
> put out a revision to evaluate against the requirements draft. It is not
> reasonable or fair to delay the adoption of this one any further until the
> requirements draft justifies the other solution.
>
>  Gyan> Agreed.  Let’s have WG and chairs and AD chime in.
>
> Thanks.
>
> Jeffrey
>
>
>
> *Sent:* Friday, November 20, 2020 3:00 PM
> *To:* [email-masked]
> Jeffrey (Zhaohui) Zhang <[email-masked]>; Tony Przygienda <
> [email-masked]>; draft-ietf-bier-ipv6-requirements <
> I will by “first round” when we meet in person — some day!!👍😁- maybe
> even second and third - or the night is on me if we can get this behind us.
> 😀
>
>
>
> Thanks
>
> Operationally as you stated as well as from the BIER layering perspective
> 2 out of the 3 layers ar identical as both have underlay and overlay and
> thus are mirrored on the encapsulation in the layering.
>
> One other significant difference between BIERin6 and BIERv6 is that
> BIERin6 is to some degree a “pseudo” IPV6 environment solution as L2 links
> direct Non MPLS Ethernet encapsulation can be used to transport BIER
> packets.  So this is HUGE has far as stark difference and major advantage
> of BIERin6 over BIERv6.
>
>
>
>     One example of this model is defined in [I-D.zhang-bier-bierin6 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-08*ref-I-D.zhang-bier-bierin6__;Iw!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guGv38Vu_$>],
>
> So as we don’t want to reinvent the wheel as we already have a solution
> for IPV6 environment, these two solutions are transitional “interim” stop
> gap measures bandaid if you will to get to the end state solution we
> already have today for IPV6 environments.
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zhang-bier-bierin6/__;!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guN2UjYuA$>
>
>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guBEzUU8q$>
>
> *Gyan Mishra*
>
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guKR8EuJa$>
> *Silver Spring, MD
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guKR8EuJa$>
>
>
>
> --
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guBEzUU8q$>
>
> *Gyan Mishra*
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
-- 

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 22 Nov 2020 13:56:48 +0000

Hi Gyan,

Please see zzh3> below.

From: Gyan Mishra <[email-masked]>
Sent: Saturday, November 21, 2020 8:45 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-bier-ipv6-requirements-09

On Sat, Nov 21, 2020 at 1:45 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
About the following:

GS - Agree.

So the requirements draft will discuss why IPv6 encapsulation is needed. As I mentioned in my previous email, even if there is a requirement for IPv6 encapsulation, BIERin6 works nicely with it, and works better with a clean layering architecture.
 Gyan> Understood.  As I stated explicitly in the response to Greg above.  What are your thoughts on what I stated that BIERin6 solution- if you remove the L2 links concept as that is Non MPLS BIER Ethernet RFC 8296 (BIERin6 L2) which already exists today and would be used for Green field IPv6 environments so imagine then the BIERin6 solution without the L2 do you agree that this solution as well as BIERv6 solutions in an IPV6 environment is strictly only for transitional brown field deployments to tunnel unicast over “non BFR capable” routers?
Zzh3> Having trouble zooming in on exactly you’re saying, but let me clarify that *BIERin6* works for *all* situations – and it is a *long term* solution:
Zzh3> 1. BIER directly over L2 links
Zzh3> 2. BIER over *any* tunnels for whatever reasons (e.g. FRR):
Zzh3>      2a. non-IPv6 tunnels
Zzh3>      2b. IPv6 based tunnels
Zzh3>             2b1. with UDP/GRE/whatever
Zzh3>             2b2. Direct IPv6 encapsulation without UDP/GRE/whatever
Zzh3>             2b3. With SRv6
Zzh3>             2b4. Without SRv6
Zzh3>             2b5. Whatever you can think of
Zzh3>  This *not* a transitional solution. It works for greenfield, brownfield, forever-field. Whatever you throw at it. A greenfield IPv6 environment still means IPv6 over L2 links and BIER can still be over L2 links directly (and it is better that way – I’ve alluded to that here and there and can discuss that separately further).
Zzh3>  As stated in the requirements draft, it is an *independent* model

Or do you think that although we already have the RFC 8286 Non MPLS BIER Ethernet solution for IPV6 environments the goal is to have additional alternatives for operators for IPV6 environments that are L2 ethernet and /or other non Ethernet link layer which would be a remaining gap as to why an IPV6 encapsulation is needed.  I guess I  am somewhat answering that why question partially but let’s say a carrier packet switched network that used GMPLS / MPLS-TP but a new architecture non MPLS based that lives in an IPV6 environment- SRv6 a candidate but prove how L2 would not work and these two proposed solutions fill the gap.

Zzh3> It is a bit hard to parse what you’re saying. As I said in my previous email, whatever the additional requirements draft discussion/work lead to (whether an IPv6 encapsulation is needed), it is *irrelevant* to the BIERin6 solution, because BIERin6 is an independent model and can work *with or without* IPv6 encapsulation nicely, because it makes use of time-proved architecture of clean layering.
Zzh3> If that discussion/work concludes that BIERv6 is warranted, it can be adopted at that time, but *there is no reason to delay the BIERin6* work.

As I stated if BIERv6 and BIERin6 are really slated to be temporary until all brown field non BFR capable routers are upgraded then we don’t need to answer the questions as this is a temporary stop gap measure.

Zzh3> I am sorry but it is *wrong* to say that BIERin6 is slated to be temporary. It is a solution that works now and for long term. If you’re specifically referring to the *optional* feature of using IPv6 encapsulation even between directly connected BFRs in the BIERin6, I want to point out that, that is a small *optional* feature that *could* be removed for now just so that we can reduce the noise level at this time so that we can focus on the fundamentals.
Zzh3> I am not sure if others will agree that BIERv6 was slated to be temporary either 😊
As such, we believe BIERin6 is already ready for adoption – though we’ll put out a revision to evaluate against the requirements draft. It is not reasonable or fair to delay the adoption of this one any further until the requirements draft justifies the other solution.
 Gyan> Agreed.  Let’s have WG and chairs and AD chime in.
Zzh3> Ah ha. Good and relieved to see “agreed” wording here. Thank you 😊
Zzh3> Jeffrey
Thanks.
Jeffrey

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Friday, November 20, 2020 3:00 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Hi Greg

In-line

Thanks

Thank you for your help.

     Gyan> Welcome

    Gyan> Understood.

   allocated by IANA.

GS - Thank you.

    Gyan> Welcome

GS - Agree.

Thanks,
Greg

Kind Regards

Gyan

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!STxhGXVn_7l3akd-22ekvXgHaktg0upH7_YQ2V4lW3xymg0-tSVfW5z4OhjypH0r$>
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!STxhGXVn_7l3akd-22ekvXgHaktg0upH7_YQ2V4lW3xymg0-tSVfW5z4OtK_wvtD$>

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

Gyan Mishra

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

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 22 Nov 2020 13:22:07 -0500

Hi Jeffrey

Please see in-line below

On Sun, Nov 22, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> *Sent:* Saturday, November 21, 2020 8:45 PM
> [email-masked] <[email-masked]>; Tony Przygienda <
> [email-masked]>; [email-masked]
> On Sat, Nov 21, 2020 at 1:45 PM Jeffrey (Zhaohui) Zhang <
>  Gyan>Understood.  As I stated explicitly in the response to Greg above.
> IPv6 environments, so imagine then the BIERin6 solution without the L2 do
> Zzh3> Having trouble zooming in on exactly you’re saying, but let me
> clarify that **BIERin6** works for **all** situations – and it is a **long
> term** solution:
>

   Gyan2>Understand and agreed long term and everything stated below all
situations, however you are missing my critical point that BIERin6 includes
an “existing solution of RFC 8296 Non MPLS BIER Ethernet 0xAB37”.  So that
already exists and to my original point and question from Greg why do we
need IPV6 encapsulation if we already have a solution for BIER over L2
links which is RFC 8296 Non MPLS BIER Ethernet 0xAB37. Because BIERin6 used
an existing solution is makes NOT a new solution for IPV6 environments.  We
end up in the circular argument.

Let’s try it another way to help explain what I am trying to convey.

Questions below.

Can BIERin6 work today in IPv6 environment?

How would it work?

Does that solution already exist?

What is that solution?

Can that solution be used for Greenfield deployments today?

Can that solution be used for Greenfield deployments in an IPV6 environment?

In the future once the BIERin6 optional feature using IPV6 encapsulation is
developed would that ever be utilized once all routers are BFR capable?

Here is the crux of the questioning.

What is the difference between BIERin6 L2 solution and RFC 8296 Non MPLS
BIER Ethernet encapsulation 0xAB37?

Are they both one and the same?

If you removed the IPv6 encapsulation optional feature from  BIERin6, what
are you left with?

Is what you are left with basically the existing solution defined in RFC
8296 Non MPLS BIER Ethernet 0xAB37?

If that is true then what is the purpose or benefit or need for BIERin6
draft if we already have that L2 encapsulation solution defined in RFC 8296
as “Non MPLS BIER Ethernet 0xAB37”?

> Zzh3> 2. BIER over **any** tunnels for whatever reasons (e.g. FRR):
>

Zzh3>  This **not** a transitional solution. It works for greenfield,
> brownfield, forever-field. Whatever you throw at it. A greenfield IPv6
> environment still means IPv6 over L2 links and BIER can still be over L2
> links directly (and it is better that way – I’ve alluded to that here and
> there and can discuss that separately further).
>
   Gyan2>Completely agree that because BIERin6 is using an existing L2
solution layering already defined in RFC 8296 Non MPLS BIER Ethernet 0xAB37
that BIERin6 draft is not introducing anything new if you exclude the IPV6
encapsulation optional feature I would agree that then BIERin6 should
really be an informational draft of how BIERin6 can be used specifically in
IPv6 environments using L2 links BFR to BFR.

> Zzh3>  As stated in the requirements draft, it is an **independent** model
>
> Gyan> Agreed using existing copyrighted technology defined in RFC 8296 so
> if you removed the IPV6 encapsulation optional feature we should downgrade
> BIERin6 to informational as it is not introducing anything new.
>
> Or do you think that although we already have the RFC 8286 Non MPLS BIER
> Ethernet solution for IPV6 environments the goal is to have additional
> an IPV6 encapsulation is needed.  I guess I  am somewhat answering that
> why question partially but let’s say a carrier packet switched network that
> Zzh3> It is a bit hard to parse what you’re saying. As I said in my
> previous email, whatever the additional requirements draft discussion/work
> lead to (whether an IPv6 encapsulation is needed), it is **irrelevant**
> to the BIERin6 solution, because BIERin6 is an independent model and can
> work **with or without** IPv6 encapsulation nicely, because it makes use
> of time-proved architecture of clean layering.
>

   Gyan2> Understood.  Yes it makes use of time proven architecture so then
my question is what is the purpose of BIERin6 draft as technically it is
not introducing anything new that requires it to be standards track.

> Zzh3> If that discussion/work concludes that BIERv6 is warranted, it can
> be adopted at that time, but **there is no reason to delay the BIERin6**
> work.
>
> Gyan2>I believe BIERin6 if you remove the IPv6 encapsulation optional
> feature then BIERin6 draft can be adopted as informational.
>
> Zzh3> I am sorry but it is **wrong** to say that BIERin6 is slated to be
> temporary. It is a solution that works now and for long term. If you’re
> specifically referring to the **optional** feature of using IPv6
> encapsulation even between directly connected BFRs in the BIERin6, I want
> to point out that, that is a small **optional** feature that **could** be
> removed for now just so that we can reduce the noise level at this time so
> that we can focus on the fundamentals.
>

   Gyan2>yes please remove and make BIERin6 informational as it is not
introducing anything new  and we can move to adopt as informational.

> Zzh3> I am not sure if others will agree that BIERv6 was slated to be

    Gyan2>I am not necessarily stating that BIERv6 is optional as we have
to answer the million $$ question as why IPV6 encapsulation is needed that
cannot be provided today with existing L2 solution. What made be even go
down that road of “temporary solution” is the question as to why BIERin6
has the L2 solution added to the solution,  almost as if the plan if you
stepped back a bit and looked at the big picture was to make the IPv6
encapsulation optional or we would not have added L2 to the BIERin6 draft
in the first place.

> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!STxhGXVn_7l3akd-22ekvXgHaktg0upH7_YQ2V4lW3xymg0-tSVfW5z4OhjypH0r$>
> *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!STxhGXVn_7l3akd-22ekvXgHaktg0upH7_YQ2V4lW3xymg0-tSVfW5z4OtK_wvtD$>
>
>
>
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!STxhGXVn_7l3akd-22ekvXgHaktg0upH7_YQ2V4lW3xymg0-tSVfW5z4Oj4pKcqJ$>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 22 Nov 2020 20:12:36 +0000

Hi Gyan,

So now the focal question about BIERin6 is should it be an informational document (if the optional IPv6 encapsulation between directly connected BFRs is removed).

The short answer is no. Please see zzh4> below.

Sent: Sunday, November 22, 2020 1:22 PM

Hi Jeffrey

Please see in-line below

On Sun, Nov 22, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Please see zzh3> below.

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, November 21, 2020 8:45 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

GS - Agree.

So the requirements draft will discuss why IPv6 encapsulation is needed. As I mentioned in my previous email, even if there is a requirement for IPv6 encapsulation, BIERin6 works nicely with it, and works better with a clean layering architecture.
 Gyan>Understood.  As I stated explicitly in the response to Greg above.  What are your thoughts on what I stated that BIERin6 solution- if you remove the L2 links concept as that is Non MPLS BIER Ethernet RFC 8296 (BIERin6 L2) which already exists today and would be used for Green field IPv6 environments, so imagine then the BIERin6 solution without the L2 do you agree that this solution as well as BIERv6 solutions in an IPV6 environment is strictly only for transitional brown field deployments to tunnel unicast over “non BFR capable” routers?
Zzh3> Having trouble zooming in on exactly you’re saying, but let me clarify that *BIERin6* works for *all* situations – and it is a *long term* solution:

   Gyan2>Understand and agreed long term and everything stated below all situations, however you are missing my critical point that BIERin6 includes an “existing solution of RFC 8296 Non MPLS BIER Ethernet 0xAB37”.  So that already exists and to my original point and question from Greg why do we need IPV6 encapsulation if we already have a solution for BIER over L2 links which is RFC 8296 Non MPLS BIER Ethernet 0xAB37. Because BIERin6 used an existing solution is makes NOT a new solution for IPV6 environments.  We end up in the circular argument.

Zzh4> Now I understand what you’re talking about.
Zzh4> Greg’s question “why do we need IPv6 encapsulation” is really for the BIERv6 solution, in particular for the BFIR->BFER case. Obviously, when tunneling is needed (e.g. to get around non-BFRs, or for FRR), IPv6 encapsulation is needed as long as the tunnel is IPv6 (w/o using GRE/UDP/similar), for both BIERin6 and BIERv6.

Zzh4> BIERin6 *optionally* uses IPv6 encapsulation even between directly connected BFRs. The draft itself already explains the scenario:

   The IPv6 encapsulation could be used even between two directly
   connected BFRs in the following two cases:

   o  An operator mandates all traffic to be carried in IPv6.

   o  A BFR does not have BIER support in its "fast forwarding path" and
      relies on "slow/software forwarding path", e.g. in environments
      like [RFC7368] where high throughput multicast forwarding
      performance is not critical.

Zzh4> Notice that the above is really no different from the case where tunneling is used between non-directly connected BFRs.
Zzh4> If the WG pushes back the above optional feature in BIERin6 until it’s been formally concluded in the requirements draft, while I think it is a bit unreasonable, we can remove the above for now and so that we can focus on the main point – existing solution can be used as is for IPv6.

Questions below.

Zzh4> Yes.

How would it work?

Zzh4> The draft already said it:
Zzh4> 1. BIER header follows L2 header between directly connected BFRs; optionally a one-hop IPv6 tunnel can be used, and then the BIER header follows the IPv6 header which follows the L2 header
Zzh4> 2. BIER header follows a tunnel header if tunneling is used (either IPv6 or some other tunnel)

Zzh4> Yes

What is that solution?

Zzh4> Existing non-MPLS BIER solution, but we do need two new code points for IPv6 environment.

Zzh4> Yes

Zzh4> Yes

In the future once the BIERin6 optional feature using IPV6 encapsulation is developed would that ever be utilized once all routers are BFR capable?

Zzh4> It could be – up to the operator and depending on the deployment situation.

What is the difference between BIERin6 L2 solution and RFC 8296 Non MPLS BIER Ethernet encapsulation 0xAB37?

Zzh4> No difference, except that similar to Ethertype 0xAB37 we need an IP “next header” type assigned when IPv6 tunneling is needed; and we need another code point for ICMP6 (see IANA consideration section of BIERin6).

Zzh4> See above.

If you removed the IPv6 encapsulation optional feature from  BIERin6, what are you left with?

Zzh4> Existing solution, which is the beauty of BIERin6. Also please note that the optional feature is applying the typically multi-hop tunneling to one-hop tunneling; BIER on top of IPv6 tunneling is not special.

Is what you are left with basically the existing solution defined in RFC 8296 Non MPLS BIER Ethernet 0xAB37?

Zzh4> Yes

If that is true then what is the purpose or benefit or need for BIERin6 draft if we already have that L2 encapsulation solution defined in RFC 8296 as “Non MPLS BIER Ethernet 0xAB37”?

Zzh4> To be exact, it is not “L2 encapsulation solution”. Existing solution does use both L2 encapsulation, and when necessary tunnel encapsulation.
Zzh4> First we need to assign an IP “next header” type for BIER (and an ICMP6 code point). Secondly, with the multi-year saga on BIER solution in IPv6 network, *it is clear how important for us to document how existing solution nicely work in an IPv6 network*. As Greg mentioned, BIERin6 did not move quickly because the optional feature was not considered by all as critical, but now with the confusion/contention introduced with BIERv6, it’s critical that we move quickly with BIERin6, even if we need to remove the optional feature temporarily if you demand that feature to be formally justified in the requirements draft first.
Zzh3> 1. BIER directly over L2 links
Zzh3> 2. BIER over *any* tunnels for whatever reasons (e.g. FRR):
Zzh3>      2a. non-IPv6 tunnels
Zzh3>      2b. IPv6 based tunnels
Zzh3>             2b1. with UDP/GRE/whatever
Zzh3>             2b2. Direct IPv6 encapsulation without UDP/GRE/whatever
Zzh3>             2b3. With SRv6
Zzh3>             2b4. Without SRv6
Zzh3>             2b5. Whatever you can think of

Zzh3>  This *not* a transitional solution. It works for greenfield, brownfield, forever-field. Whatever you throw at it. A greenfield IPv6 environment still means IPv6 over L2 links and BIER can still be over L2 links directly (and it is better that way – I’ve alluded to that here and there and can discuss that separately further).
   Gyan2>Completely agree that because BIERin6 is using an existing L2 solution layering already defined in RFC 8296 Non MPLS BIER Ethernet 0xAB37 that BIERin6 draft is not introducing anything new if you exclude the IPV6 encapsulation optional feature I would agree that then BIERin6 should really be an informational draft of how BIERin6 can be used specifically in IPv6 environments using L2 links BFR to BFR.

Zzh4> It can’t be informational, for the reasons that I stated above.
Zzh3>  As stated in the requirements draft, it is an *independent* model
Gyan> Agreed using existing copyrighted technology defined in RFC 8296 so if you removed the IPV6 encapsulation optional feature we should downgrade BIERin6 to informational as it is not introducing anything new.
Or do you think that although we already have the RFC 8286 Non MPLS BIER Ethernet solution for IPV6 environments the goal is to have additional alternatives for operators for IPV6 environments that are L2 ethernet and /or other non Ethernet link layer which would be a remaining gap as to why an IPV6 encapsulation is needed.  I guess I  am somewhat answering that why question partially but let’s say a carrier packet switched network that used GMPLS / MPLS-TP but a new architecture non MPLS based that lives in an IPV6 environment- SRv6 a candidate but prove how L2 would not work and these two proposed solutions fill the gap.

   Gyan2> Understood.  Yes it makes use of time proven architecture so then my question is what is the purpose of BIERin6 draft as technically it is not introducing anything new that requires it to be standards track.

Zzh4> Please see above.
Zzh3> If that discussion/work concludes that BIERv6 is warranted, it can be adopted at that time, but *there is no reason to delay the BIERin6* work.
Gyan2>I believe BIERin6 if you remove the IPv6 encapsulation optional feature then BIERin6 draft can be adopted as informational.
Zzh4> It can’t be informational for the reasons stated above.
As I stated if BIERv6 and BIERin6 are really slated to be temporary until all brown field non BFR capable routers are upgraded then we don’t need to answer the questions as this is a temporary stop gap measure.

   Gyan2>yes please remove and make BIERin6 informational as it is not introducing anything new  and we can move to adopt as informational.

Zzh4> Please see above why it can’t be informational.
Zzh3> I am not sure if others will agree that BIERv6 was slated to be temporary either 😊

Gyan2>I am not necessarily stating that BIERv6 is optional as we have to answer the million $$ question as why IPV6 encapsulation is needed that cannot be provided today with existing L2 solution. What made be even go down that road of “temporary solution” is the question as to why BIERin6 has the L2 solution added to the solution,  almost as if the plan if you stepped back a bit and looked at the big picture was to make the IPv6 encapsulation optional or we would not have added L2 to the BIERin6 draft in the first place.

Zzh4> Please see earlier responses.
Zzh4> Thanks!
Zzh4> Jeffrey
As such, we believe BIERin6 is already ready for adoption – though we’ll put out a revision to evaluate against the requirements draft. It is not reasonable or fair to delay the adoption of this one any further until the requirements draft justifies the other solution.
 Gyan> Agreed.  Let’s have WG and chairs and AD chime in.
Zzh3> Ah ha. Good and relieved to see “agreed” wording here. Thank you 😊
Zzh3> Jeffrey
Thanks.
Jeffrey

Hi Greg

In-line

Thanks

Thank you for your help.

     Gyan> Welcome

    Gyan> Understood.

   allocated by IANA.

GS - Thank you.

    Gyan> Welcome

GS - Agree.

Thanks,
Greg

Kind Regards

Gyan

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!U4fWui9a6AMmox_9HVOLuabWQsSUE43xFjGNG7ozUqEhzJuXaluJlznN0z_yUTbt$>
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!U4fWui9a6AMmox_9HVOLuabWQsSUE43xFjGNG7ozUqEhzJuXaluJlznN02rdMzHa$>

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

Gyan Mishra

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

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 22 Nov 2020 16:18:54 -0500

Hi Jeffrey

This has been a very informative exchange and extremely helpful for all of
us to get onto the same page from a basic understanding POV.

Much appreciated all your help and feedback helping clarify my confusion.

I am answering in-line but now connecting the dots how is in today’s RFC
8296 Non MPLS BIER Ethernet going to transport IPv6?

>From your answers below it cannot work as we need two IANA code point one
for IPv6 next header type and ICMPv6.

And it is for this reason BIERin6 even with optional IPv6 encapsulation
removed, does in fact even for L2, BIERin6 introduces something new being
the two code points for IPV6 environment and thus must be standards track.

Do you agree with my overall assessment?

In-line Gyan3>

On Sun, Nov 22, 2020 at 3:12 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi Gyan,
>
>
>
> So now the focal question about BIERin6 is should it be an informational
> document (if the optional IPv6 encapsulation between directly connected
> BFRs is removed).
>
>
>
> *Sent:* Sunday, November 22, 2020 1:22 PM
> On Sun, Nov 22, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <
>    Gyan3> Glad we are in sync!

Zzh4> Greg’s question “why do we need IPv6 encapsulation” is really for the
> BIERv6 solution, in particular for the BFIR->BFER case. Obviously, when
> tunneling is needed (e.g. to get around non-BFRs, or for FRR), IPv6
> encapsulation is needed as long as the tunnel is IPv6 (w/o using
> GRE/UDP/similar), for both BIERin6 and BIERv6.
>
>  Gyan> Agreed.  That is why I was thinking temporary but I think having in
> operators toolbox of options is extremely helpful even in future where all
> hardware is upgraded BFR capable their maybe a need to use IPV6
> encapsulation and not L2.  So I am in agreement we can definitely define
> reasons for why we need IPV6 encapsulation for future end state and not
> just interim transitional solution.
>
> Zzh4> BIERin6 **optionally** uses IPv6 encapsulation even between
> directly connected BFRs. The draft itself already explains the scenario:
>
>
>
    Gyan> Good point.  So not only non directly connected “non BFRs” but
directly connected “non BFRs” but important point that operator mandates
traffic carried in IPv6.  That justification could definitely answer at
least one of the “why” reasons for IPV6 encapsulation as we build the list.

> Zzh4> Notice that the above is really no different from the case where
> tunneling is used between non-directly connected BFRs.
>

   Gyan3> Good point Agreed

> Zzh4> If the WG pushes back the above optional feature in BIERin6 until
> it’s been formally concluded in the requirements draft, while I think it is
> a bit unreasonable, we can remove the above for now and so that we can
> focus on the main point – existing solution can be used as is for IPv6.
>
>  Gyan> This thread is really helpful in getting both of is completely and
> fully synced up.  And as we get synced up I don’t think we want to remove
> the optimal feature.  Let’s wait for this thread to play out but so far I
> am thinking we keep optional in place.
>
> Zzh4> 1. BIER header follows L2 header between directly connected BFRs;
> optionally a one-hop IPv6 tunnel can be used, and then the BIER header
> follows the IPv6 header which follows the L2 header
>
> In the future once the BIERin6 optional feature using IPV6 encapsulation
> is developed would that ever be utilized once all routers are BFR capable?
>
>
>
> Zzh4> No difference, except that similar to Ethertype 0xAB37 we need an IP
> “next header” type assigned when IPv6 tunneling is needed; and we need
> another code point for ICMP6 (see IANA consideration section of BIERin6).
>
>
>
> Zzh4> Existing solution, which is the beauty of BIERin6. Also please note
> that the optional feature is applying the typically multi-hop tunneling to
> one-hop tunneling; BIER on top of IPv6 tunneling is not special.
>
>  Gyan3> Understood.  Similar proven layering techniques
>
> Zzh4> To be exact, it is not “L2 encapsulation solution”. Existing
> solution does use both L2 encapsulation, and when necessary tunnel
> encapsulation.
>
> Zzh4> First we need to assign an IP “next header” type for BIER (and an
> ICMP6 code point). Secondly, with the multi-year saga on BIER solution in
> IPv6 network, **it is clear how important for us to document how existing
> solution nicely work in an IPv6 network**. As Greg mentioned, BIERin6 did
> not move quickly because the optional feature was not considered by all as
> critical, but now with the confusion/contention introduced with BIERv6,
> it’s critical that we move quickly with BIERin6, even if we need to remove
> the optional feature temporarily if you demand that feature to be formally
> justified in the requirements draft first.
>

    Gyan3> Agreed with everything stated. So that is the gap and the two
new code point allocations is what net new that gets added in the BIERin6
draft even if the optional IPv6 encapsulation was excluded

> Zzh4> It can’t be informational, for the reasons that I stated above.
   Gyan3>Agreed and understand we need the two codepoints allocated for L2
BIER to work in an IPv6 environment even if we excluded the optional IPV6
encapsulation.

>    Gyan2> Understood.  Yes it makes use of time proven architecture so
> then my question is what is the purpose of BIERin6 draft as technically it
> is not introducing anything new that requires it to be standards track.
>
>
>
> Zzh4> Please see above.
>
> Gyan2>I am not necessarily stating that BIERv6 is optional as we have to
> answer the million $$ question as why IPV6 encapsulation is needed that
> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>
>
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!U4fWui9a6AMmox_9HVOLuabWQsSUE43xFjGNG7ozUqEhzJuXaluJlznN0z_yUTbt$>
> *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!U4fWui9a6AMmox_9HVOLuabWQsSUE43xFjGNG7ozUqEhzJuXaluJlznN02rdMzHa$>
>
>
>
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!U4fWui9a6AMmox_9HVOLuabWQsSUE43xFjGNG7ozUqEhzJuXaluJlznN03dja8EJ$>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Nov 2020 01:06:45 +0000

Hi Gyan,

Yes I believe we’ve reached consensus.

Please see zzh5> below about some details.

Sent: Sunday, November 22, 2020 4:19 PM

Hi Jeffrey

This has been a very informative exchange and extremely helpful for all of us to get onto the same page from a basic understanding POV.

I am answering in-line but now connecting the dots how is in today’s RFC 8296 Non MPLS BIER Ethernet going to transport IPv6?

From your answers below it cannot work as we need two IANA code point one for IPv6 next header type and ICMPv6.

Zzh5> The existing model/concept works except that we need to two code points if IPv6 tunneling is used for either getting over non-BFRs or for FRR. One may deem non-BFR as a short-term scenario but FRR will be here for the long run.

And it is for this reason BIERin6 even with optional IPv6 encapsulation removed, does in fact even for L2, BIERin6 introduces something new being the two code points for IPV6 environment and thus must be standards track.

Zzh5> “even for L2” is not exactly right. It is when IPv6 tunneling is needed (for non-BFR or for FRR – and that is different from the optional IPv6 encapsulation between directly connected BFRs) where the two new code points are needed.

Zzh5> Yes but minus the above minor detail. More zzh5> below.

In-line Gyan3>

On Sun, Nov 22, 2020 at 3:12 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Hi Jeffrey

Please see in-line below

Please see zzh3> below.

GS - Agree.

Zzh4> Greg’s question “why do we need IPv6 encapsulation” is really for the BIERv6 solution, in particular for the BFIR->BFER case. Obviously, when tunneling is needed (e.g. to get around non-BFRs, or for FRR), IPv6 encapsulation is needed as long as the tunnel is IPv6 (w/o using GRE/UDP/similar), for both BIERin6 and BIERv6.
 Gyan> Agreed.  That is why I was thinking temporary but I think having in operators toolbox of options is extremely helpful even in future where all hardware is upgraded BFR capable their maybe a need to use IPV6 encapsulation and not L2.  So I am in agreement we can definitely define reasons for why we need IPV6 encapsulation for future end state and not just interim transitional solution.
Zzh4> BIERin6 *optionally* uses IPv6 encapsulation even between directly connected BFRs. The draft itself already explains the scenario:

    Gyan> Good point.  So not only non directly connected “non BFRs” but directly connected “non BFRs” but important point that operator mandates traffic carried in IPv6.  That justification could definitely answer at least one of the “why” reasons for IPV6 encapsulation as we build the list.
Zzh4> Notice that the above is really no different from the case where tunneling is used between non-directly connected BFRs.

   Gyan3> Good point Agreed

Zzh5> Notice that for the requirements draft, when you talk about IPv6 encapsulation, there is a need to distinguish between BFIR->BFER multi-hop IPv6 encapsulation (as currently used in BIERv6) and hop-by-hop encapsulation. We can discuss that separately.
Zzh4> If the WG pushes back the above optional feature in BIERin6 until it’s been formally concluded in the requirements draft, while I think it is a bit unreasonable, we can remove the above for now and so that we can focus on the main point – existing solution can be used as is for IPv6.
 Gyan> This thread is really helpful in getting both of is completely and fully synced up.  And as we get synced up I don’t think we want to remove the optimal feature.  Let’s wait for this thread to play out but so far I am thinking we keep optional in place.
Let’s try it another way to help explain what I am trying to convey.

Questions below.

Zzh4> Yes.

How would it work?

Zzh4> Yes

What is that solution?

Zzh4> Yes

Zzh4> Yes

Zzh4> See above.

Zzh4> Yes

Gyan3> Agreed with everything stated. So that is the gap and the two new code point allocations is what net new that gets added in the BIERin6 draft even if the optional IPv6 encapsulation was excluded

Zzh5> To be exact, the optional IPv6 encapsulation is for between directly connected BFRs. Even when we exclude that one, If there are non-BFR or FRR situation, then IPv6 encapsulation and two new code points are needed (unless you use GRE/UDP/MPLS/other tunnels), but that IPv6 encapsulation is nothing different from any other types of tunnels.

Zzh4> It can’t be informational, for the reasons that I stated above.
   Gyan3>Agreed and understand we need the two codepoints allocated for L2 BIER to work in an IPv6 environment even if we excluded the optional IPV6 encapsulation.

Zzh5> To be exact, replace “L2 BIER” with “BIER over L2/tunnel” (which is an existing solution/model/concept), and add “between directly connected BFRs” after “optional IPv6 encapsulation”.
Zzh5> Jeffrey
Zzh3>  As stated in the requirements draft, it is an *independent* model
Gyan> Agreed using existing copyrighted technology defined in RFC 8296 so if you removed the IPV6 encapsulation optional feature we should downgrade BIERin6 to informational as it is not introducing anything new.
Or do you think that although we already have the RFC 8286 Non MPLS BIER Ethernet solution for IPV6 environments the goal is to have additional alternatives for operators for IPV6 environments that are L2 ethernet and /or other non Ethernet link layer which would be a remaining gap as to why an IPV6 encapsulation is needed.  I guess I  am somewhat answering that why question partially but let’s say a carrier packet switched network that used GMPLS / MPLS-TP but a new architecture non MPLS based that lives in an IPV6 environment- SRv6 a candidate but prove how L2 would not work and these two proposed solutions fill the gap.

Zzh4> Please see above.

Hi Greg

In-line

Thanks

Thank you for your help.

     Gyan> Welcome

    Gyan> Understood.

   allocated by IANA.

GS - Thank you.

    Gyan> Welcome

GS - Agree.

Thanks,
Greg

Kind Regards

Gyan

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!VCcJaZ8dtXUa9f6ssLdDxnziiSu3Yr8ckb108w5pho5p919JLUS76hRQuWI6UOan$>
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!VCcJaZ8dtXUa9f6ssLdDxnziiSu3Yr8ckb108w5pho5p919JLUS76hRQuXLf1KCq$>

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

Gyan Mishra

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

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 22 Nov 2020 21:48:58 -0500

Hi Jeffrey

Agreed we have reached a consensus.

Few more questions to iron out understanding.

In line gyan4>

On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> *Sent:* Sunday, November 22, 2020 4:19 PM
> Zzh5> The existing model/concept works except that we need to two code
> points if IPv6 tunneling is used for either getting over non-BFRs or for
> FRR. One may deem non-BFR as a short-term scenario but FRR will be here for
> the long run.
>
>
>
    Gyan4>I am a little confused here with the code points.  For BIERin6
“L2” BIER scenario RFC 8296 Non MPLS BIER Ethernet Ether type 0xAB37.

Ethernet -0xAB37 l BIER | IPv6 | payload

Ethernet -0xAB37 l BIER l ICMPv6 | payload

In this particular scenario where adjacent BFRs support Ethernet link layer
in an IPV6 environment and  IPv6 or ICMPv6 encapsulation and the need for
the next header code point above is the packet format:

Excerpt from RFC 8296

Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet
   header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332
<https://tools.ietf.org/html/rfc5332>].  IEEE
   has assigned Ethertype 0xAB37 for non-MPLS BIER packets.

In the case of BIERin6 optional encapsulation option, in case where
operators requires packets forwarded in IPv6 or tunneling over Non BFR
packet format below:

IPv6 outer header l BIER l Data

So here the next header is BIER so corresponding next header code point.

So below is for both cases IANA code point allocation for “L2” next header
where next header is IPv6 or ICMPV6, and then the optional IPv6
encapsulation option where the next header is BIER.

Would those be two separate IANA code point requests I what I see from the
packet format.

IANA L2 scenario:
2 code point requests for L2 for next header IPv6 and ICMP

IANA optional IPv6 scenario:
1 code point request for IPv6 for next header BIER

5 <https://tools.ietf.org/html/draft-zhang-bier-bierin6-07#section-5>.
IANA Considerations

   IANA is requested to assign a new "BIER" type for "Next Header" in
   the "Assigned Internet Protocol Numbers" registry.

   IANA is requested to assign a new "BIERin6" type for "invalid
   options" in the "ICMP code value" registry.

   IANA is requested to assign a new "BIER IPv6 transportation Sub-sub-
   TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV"
   Registry.

   IANA is requested to set up a new "BIER IPv6 transportation Sub-sub-
   sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation sub-sub-TLV"
   Registry.

My point is that the IANA allocation is different as the next header is
different for the L2 scenario where next header is IPv6 or ICMPV6, and IPv6
encapsulation scenario where the next header is BIER.

Based on this point I am making could we just do a RFC8296 bis version and
add the IANA code points for IPv6 and ICMPv6.

The BIERin6 draft would be much cleaner  and less confusing and also have
direct parity with BIERv6 as now they both are geared to IPV6 environment
solution IPV6 encapsulation use case.

> Zzh5> “even for L2” is not exactly right. It is when IPv6 tunneling is
> needed (for non-BFR or for FRR – and that is different from the optional
> IPv6 encapsulation between directly connected BFRs) where the two new code
> points are needed.
>
>  Gyan4>  For directly connected BFRs with L2 Ethernet RFC 8296 0xAB37, how
> are you using IPv6 tunneling?
>
    With BIERin6 the Unicast tunneling over non BFRs can only be done with
optional IPv6 encapsulation tunneling option.

> On Sun, Nov 22, 2020 at 3:12 PM Jeffrey (Zhaohui) Zhang <
> Zzh4> Greg’s question “why do we need IPv6 encapsulation” is really for
> the BIERv6 solution, in particular for the BFIR->BFER case. Obviously,
> when tunneling is needed (e.g. to get around non-BFRs, or for FRR), IPv6
> Zzh5> Notice that for the requirements draft, when you talk about IPv6
> encapsulation, there is a need to distinguish between BFIR->BFER multi-hop
> IPv6 encapsulation (as currently used in BIERv6) and hop-by-hop
> encapsulation. We can discuss that separately.
>

    Gyan4> Understood.  The main difference is BIERin6 optional IPV6
environment solution involves encapsulation and decapsulation at BFR
endpoints, where BIERv6 is multi-hop IPv6 encapsulation.

> Gyan3> Agreed with everything stated. So that is the gap and the two new
> code point allocations is what net new that gets added in the BIERin6 draft
> even if the optional IPv6 encapsulation was excluded
>
>
>
> Zzh5> To be exact, the optional IPv6 encapsulation is for between directly
> connected BFRs. Even when we exclude that one, If there are non-BFR or FRR
> situation, then IPv6 encapsulation and two new code points are needed
> (unless you use GRE/UDP/MPLS/other tunnels), but that IPv6 encapsulation is
> nothing different from any other types of tunnels.
>

     Gyan4>  Please see the beginning of the email. I disagree.  See the
packet format displayed.

> Zzh5> To be exact, replace “L2 BIER” with “BIER over L2/tunnel” (which is
> an existing solution/model/concept), and add “between directly connected
> BFRs” after “optional IPv6 encapsulation”.
>

    Gyan4> I am not following.  My understanding is  L2 would be used for
adjacent Ethernet  BFRs and to tunnel over Non BFRs the  optional IPv6
tunnel solution would be used.

> *M 301 502-1347 **13101 Columbia Pike *
> <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!VCcJaZ8dtXUa9f6ssLdDxnziiSu3Yr8ckb108w5pho5p919JLUS76hRQuWI6UOan$>
> *
> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver+Spring,%0D%0A+MD?entry=gmail&source=g>*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!VCcJaZ8dtXUa9f6ssLdDxnziiSu3Yr8ckb108w5pho5p919JLUS76hRQuXLf1KCq$>
>
>
>
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!VCcJaZ8dtXUa9f6ssLdDxnziiSu3Yr8ckb108w5pho5p919JLUS76hRQufRfSwY9$>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Nov 2020 03:39:24 +0000

Gyan,

Please see zzh6> below.

Sent: Sunday, November 22, 2020 9:49 PM

Hi Jeffrey

In line gyan4>

Zzh6> Apparently there are still disconnects 😊

On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Hi Jeffrey

    Gyan4>I am a little confused here with the code points.  For BIERin6 “L2” BIER scenario RFC 8296 Non MPLS BIER Ethernet Ether type 0xAB37.

Zzh6> Note that IPv6 header is not needed – it should be Ethernet -0xAB37 l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6 header may be inserted between BIER and payload, only for the SRv6 style VPN purpose.

Zzh6> ICMP was mentioned not for encapsulation but for the following:

Zzh6> 2.1.  IPv6 Options Considerations

   For directly connected BIER routers, IPv6 Hop-by-Hop or Destination
   options are irrelevant and SHOULD NOT be inserted by BFIR on the
   BIERin6 packet.  In this case IPv6 header, Next Header field should
   be set to TBD.  Any IPv6 packet arriving on BFRs and BFERs, with
   multiple extension header where the last extension header has a Next
   Header field set to TBD, SHOULD be discard and the node should
   transmit an ICMP Parameter Problem message to the source of the
   packet (BFIR) with an ICMP code value of TBD10 ('invalid options for
   BIERin6').

In this particular scenario where adjacent BFRs support Ethernet link layer in an IPV6 environment and  IPv6 or ICMPv6 encapsulation and the need for the next header code point above is the packet format:

Excerpt from RFC 8296

   header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc5332__;!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ84ssHlj$>].  IEEE

In the case of BIERin6 optional encapsulation option, in case where operators requires packets forwarded in IPv6 or tunneling over Non BFR packet format below:

So below is for both cases IANA code point allocation for “L2” next header where next header is IPv6 or ICMPV6, and then the optional IPv6 encapsulation option where the next header is BIER.

Would those be two separate IANA code point requests I what I see from the packet format.

IANA L2 scenario:

Zzh6> I don’t follow what you’re talking about. If BIER header follows L2 header directly, no new code point is needed. It’s just “Ethernet 0xAB37 | BIER | payload”.

Zzh6> If IPv6 encapsulation is used, either on between directly connected BFRs or indirectly connected BFRs, a new “next header” code point is needed for BIER.

5<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zhang-bier-bierin6-07*section-5__;Iw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH$>.  IANA Considerations

   Registry.

   Registry.

My point is that the IANA allocation is different as the next header is different for the L2 scenario where next header is IPv6 or ICMPV6, and IPv6 encapsulation scenario where the next header is BIER.

Zzh6> If BIER header follows L2 header directly, BIER Ethertype is used (assuming Ethernet is the L2).

Based on this point I am making could we just do a RFC8296 bis version and add the IANA code points for IPv6 and ICMPv6.

Zzh6> Given the confusion/contention that have happened in the last two years, it is much better to specifically have a spec dedicated to supporting BIER in IPv6.

The BIERin6 draft would be much cleaner  and less confusing and also have direct parity with BIERv6 as now they both are geared to IPV6 environment solution IPV6 encapsulation use case.

Zzh5> “even for L2” is not exactly right. It is when IPv6 tunneling is needed (for non-BFR or for FRR – and that is different from the optional IPv6 encapsulation between directly connected BFRs) where the two new code points are needed.
 Gyan4>  For directly connected BFRs with L2 Ethernet RFC 8296 0xAB37, how are you using IPv6 tunneling?
Zzh6> This is the disconnect that I mentioned at the very top.
Zzh6> If IPv6 tunneling is needed between directly connected BFRs, the 0xAB37 is *not* used. Rather it is the following:
Zzh6> “Ethernet  0x86DD (IPv6) | IPv6 | BIER | payload”.

  With BIERin6 the Unicast tunneling over non BFRs can only be done with optional IPv6 encapsulation tunneling option.
Do you agree with my overall assessment?

In-line Gyan3>

Hi Jeffrey

Please see in-line below

Please see zzh3> below.

GS - Agree.

   Gyan3> Good point Agreed

Gyan4> Understood.  The main difference is BIERin6 optional IPV6 environment solution involves encapsulation and decapsulation at BFR endpoints, where BIERv6 is multi-hop IPv6 encapsulation.
Zzh6> Note that it is optional, per the operator’s choice (to mandate IPv6 always).
Zzh4> If the WG pushes back the above optional feature in BIERin6 until it’s been formally concluded in the requirements draft, while I think it is a bit unreasonable, we can remove the above for now and so that we can focus on the main point – existing solution can be used as is for IPv6.
 Gyan> This thread is really helpful in getting both of is completely and fully synced up.  And as we get synced up I don’t think we want to remove the optimal feature.  Let’s wait for this thread to play out but so far I am thinking we keep optional in place.
Let’s try it another way to help explain what I am trying to convey.

Questions below.

Zzh4> Yes.

How would it work?

Zzh4> Yes

What is that solution?

Zzh4> Yes

Zzh4> Yes

Zzh4> See above.

Zzh4> Yes

     Gyan4>  Please see the beginning of the email. I disagree.  See the packet format displayed.
Zzh6> Please see my earlier response.
Zzh3> 1. BIER directly over L2 links
Zzh3> 2. BIER over *any* tunnels for whatever reasons (e.g. FRR):
Zzh3>      2a. non-IPv6 tunnels
Zzh3>      2b. IPv6 based tunnels
Zzh3>             2b1. with UDP/GRE/whatever
Zzh3>             2b2. Direct IPv6 encapsulation without UDP/GRE/whatever
Zzh3>             2b3. With SRv6
Zzh3>             2b4. Without SRv6
Zzh3>             2b5. Whatever you can think of

Gyan4> I am not following.  My understanding is  L2 would be used for adjacent Ethernet  BFRs and to tunnel over Non BFRs the  optional IPv6 tunnel solution would be used.

Zzh6> No.
Zzh6> Between adjacent BFRs, you can use either 0xAB37 w/o one-hop IPv6 tunneling, or *optionally* not use 0xAB37 but use one-hop IPv6 tunneling (that is the “optional IPv6 encapsulation” that I have been talking about).
Zzh6> Using one-hop IPv6 tunneling in case of adjacent BFRs is no different from using IPv6 tunneling over non-BFRs (or for FRR purpose), and for the latter (non-BFR or FRR), tunneling is *not optional* (though of course you can use other types of tunnels instead of IPv6).
Zzh6> Jeffrey
Zzh5> Jeffrey
Zzh3>  As stated in the requirements draft, it is an *independent* model
Gyan> Agreed using existing copyrighted technology defined in RFC 8296 so if you removed the IPV6 encapsulation optional feature we should downgrade BIERin6 to informational as it is not introducing anything new.
Or do you think that although we already have the RFC 8286 Non MPLS BIER Ethernet solution for IPV6 environments the goal is to have additional alternatives for operators for IPV6 environments that are L2 ethernet and /or other non Ethernet link layer which would be a remaining gap as to why an IPV6 encapsulation is needed.  I guess I  am somewhat answering that why question partially but let’s say a carrier packet switched network that used GMPLS / MPLS-TP but a new architecture non MPLS based that lives in an IPV6 environment- SRv6 a candidate but prove how L2 would not work and these two proposed solutions fill the gap.

Zzh4> Please see above.

Hi Greg

In-line

Thanks

Thank you for your help.

     Gyan> Welcome

    Gyan> Understood.

   allocated by IANA.

GS - Thank you.

    Gyan> Welcome

GS - Agree.

Thanks,
Greg

Kind Regards

Gyan

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

Gyan Mishra

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!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQy23miVM$>
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!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQy23miVM$>

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

Gyan Mishra

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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 23 Nov 2020 01:31:46 -0500

Hi Jeffrey

That’s the last of my questions related to BIERin6.

I thank you for taking the time to go over the BIERin6 draft in detail.

We have reached consensus as well as are in sync,  and I now have a better
understanding of BIERin6.

During the discussions I did mention that maybe in BIERin6 optional IPv6
tunneling should be removed, as it seemed to create some confusion, but now
I am clear and as both the L2/tunnel and IPv6 L3/tunnel encapsulation
single hop or multi hop tunnel both have the clean BIER layering and
complement each other I agree they belong together in the same draft.
Even though L2/tunnel exists today as part of RFC8296 it makes sense to be
part of the overall BIERin6 solution.

I am clear on the two IANA code points requests required for the optional
IPV6 encapsulation option.

Over the course of this thread we did touch on some technical reasons why
IPV6 encapsulation is necessary which I you mentioned in some of your
responses.

Overall throughout the discussions I agree that BIERin6 IPV6 tunnel option
and BIERv6 are not transitional and are long term solutions and there are
reasons why that we can add to the requirements draft as to why IPV6
encapsulation is necessary below:

- Operator requirement for IPV6 encapsulated packets  and not L2
encapsulation.
-FRR

I think we are all set to start updating the Requirements draft.

In-line Gyan6>

Kind Regards

Gyan

On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> *Sent:* Sunday, November 22, 2020 9:49 PM
>  Gyan> Thank you for all the detailed responses.  We are in sync now!
>
> On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <
> Zzh6> Note that IPv6 header is not needed – it should be Ethernet -0xAB37
> l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6
> header may be inserted between BIER and payload, only for the SRv6 style
> VPN purpose.
> Gyan> Understood
>
>  Gyan6>Understood
> In this particular scenario where adjacent BFRs support Ethernet link
> layer in an IPV6 environment and  IPv6 or ICMPv6 encapsulation and the need
> for the next header code point above is the packet format:
>
>
>
> Excerpt from RFC 8296
>
>
>
>    header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc5332__;!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ84ssHlj$>].  IEEE
>
> Zzh6> I don’t follow what you’re talking about. If BIER header follows L2
> header directly, no new code point is needed. It’s just “Ethernet 0xAB37 |
> BIER | payload”.
>

    Gyan6> Agreed.

> Zzh6> If IPv6 encapsulation is used, either on between directly connected
> BFRs or indirectly connected BFRs, a new “next header” code point is needed
> for BIER.
>
>  Gyan6>Understood
>
>
> 5
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zhang-bier-bierin6-07*section-5__;Iw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH$>.
> IANA Considerations
>
>
>
>
>
>  Gyan>Understood
> Zzh6> Given the confusion/contention that have happened in the last two
> years, it is much better to specifically have a spec dedicated to
> supporting BIER in IPv6.
>
>  Gyan6> I think now looking at it holistically speaking I can now see
> parity between the L2/tunnel and L3/tunnel both also having the clean
> layering.  So I can see why adding existing L2/tunnel to BIERin6 even
> though it already exists made sense to bundle into BIERin6 total solution.
>
> Zzh6> If IPv6 tunneling is needed between directly connected BFRs, the
> 0xAB37 is **not** used. Rather it is the following:
>
> Gyan6> Yep standard IANA ether type for IPv6
>
> Zzh6> Between adjacent BFRs, you can use either 0xAB37 w/o one-hop IPv6
> tunneling, or **optionally** not use 0xAB37 but use one-hop IPv6
> tunneling (that is the “optional IPv6 encapsulation” that I have been
> talking about).
>
> Zzh6> Using one-hop IPv6 tunneling in case of adjacent BFRs is no
> different from using IPv6 tunneling over non-BFRs (or for FRR purpose), and
> for the latter (non-BFR or FRR), tunneling is **not optional** (though of
> course you can use other types of tunnels instead of IPv6).
>
> Zzh6> Jeffrey
>
> Zzh5> Jeffrey
>
> <https://www.google.com/maps/search/13101%0D%0A+Columbia+Pike+%0D%0A+Silver%0D%0A+Spring,+MD?entry=gmail&source=g>*Silver
> Spring, MD

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Nov 2020 12:56:00 +0000

Hi Gyan,

Great that we reached consensus on BIERin6.
Now there are two lingering points alluded to in this thread, but given it’s been such a long and deeply nested tread, I’ll start a new thread about it.

Thanks.
Jeffrey

Sent: Monday, November 23, 2020 1:32 AM

Hi Jeffrey

We have reached consensus as well as are in sync,  and I now have a better understanding of BIERin6.

During the discussions I did mention that maybe in BIERin6 optional IPv6 tunneling should be removed, as it seemed to create some confusion, but now I am clear and as both the L2/tunnel and IPv6 L3/tunnel encapsulation single hop or multi hop tunnel both have the clean BIER layering and complement each other I agree they belong together in the same draft.
Even though L2/tunnel exists today as part of RFC8296 it makes sense to be part of the overall BIERin6 solution.

I am clear on the two IANA code points requests required for the optional IPV6 encapsulation option.

Over the course of this thread we did touch on some technical reasons why IPV6 encapsulation is necessary which I you mentioned in some of your responses.

Overall throughout the discussions I agree that BIERin6 IPV6 tunnel option and BIERv6 are not transitional and are long term solutions and there are reasons why that we can add to the requirements draft as to why IPV6 encapsulation is necessary below:

- Operator requirement for IPV6 encapsulated packets  and not L2 encapsulation.
-FRR

In-line Gyan6>

Kind Regards

Gyan

On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

Please see zzh6> below.

Hi Jeffrey

In line gyan4>

Hi Jeffrey

Excerpt from RFC 8296

IANA L2 scenario:

    Gyan6> Agreed.

   Registry.

   Registry.

Zzh6> Given the confusion/contention that have happened in the last two years, it is much better to specifically have a spec dedicated to supporting BIER in IPv6.
 Gyan6> I think now looking at it holistically speaking I can now see parity between the L2/tunnel and L3/tunnel both also having the clean layering.  So I can see why adding existing L2/tunnel to BIERin6 even though it already exists made sense to bundle into BIERin6 total solution.
The BIERin6 draft would be much cleaner  and less confusing and also have direct parity with BIERv6 as now they both are geared to IPV6 environment solution IPV6 encapsulation use case.

In-line Gyan3>

Hi Jeffrey

Please see in-line below

Please see zzh3> below.

GS - Agree.

   Gyan3> Good point Agreed

Questions below.

Zzh4> Yes.

How would it work?

Zzh4> Yes

What is that solution?

Zzh4> Yes

Zzh4> Yes

Zzh4> See above.

Zzh4> Yes

Zzh6> No.

Zzh4> Please see above.

Hi Greg

In-line

Thanks

Thank you for your help.

     Gyan> Welcome

    Gyan> Understood.

   allocated by IANA.

GS - Thank you.

    Gyan> Welcome

GS - Agree.

Thanks,
Greg

Kind Regards

Gyan

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

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

Gyan Mishra

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

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 24 Nov 2020 20:34:00 -0500

Jeffrey

About the two lingering points it does shed light on something that has
been disturbing me with the BIERin6 solution.

I thought about this some more and I think what creates a lot of confusion
in my mind with BIERin6 solution is the L2/tunnel component.

As the main reason is that the L2/tunnel exists today with RFC 8296 “Non
MPLS BIER Ethernet” with the special allocated next header code point to
account for BIER next header 0xAB37.

I honestly think the L2 should be removed from the BIERin6 draft so that
the optional IPV6 encapsulation is no longer “optional” in the draft as
that now is the draft.

This also provides the “IPv6 encapsulation” commonality with BIERv6 at
least showing clearly that their is a strive for commonality and parity
between the two solutions.

Also the “muddying” of the water is eliminated by removing L2 making the
solution crystal clear to operators.

Kind Regards

Gyan

On Mon, Nov 23, 2020 at 7:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Now there are two lingering points alluded to in this thread, but given
> it’s been such a long and deeply nested tread, I’ll start a new thread
> about it.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> *Sent:* Monday, November 23, 2020 1:32 AM
> On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <
> *M 301 502-1347 *

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 25 Nov 2020 13:35:32 +0000

Hi Gyan,

I have to disagree.

It took me quite a while to get the point through, that BIER over L2 directly can work in an IPv6 network.

The draft is about “BIER support in IPv6”, so it is naturally to include both BIER over L2 and over tunnels (IPv6 or not).

The multi-year saga of BIERin6/BIERv6, and this long/nested thread have make it super clear that it is necessary to explain how BIER can work in an IPv6 network, and BIERin6 does that exactly.

Jeffrey

Sent: Tuesday, November 24, 2020 8:34 PM

Jeffrey

About the two lingering points it does shed light on something that has been disturbing me with the BIERin6 solution.

I thought about this some more and I think what creates a lot of confusion in my mind with BIERin6 solution is the L2/tunnel component.

As the main reason is that the L2/tunnel exists today with RFC 8296 “Non MPLS BIER Ethernet” with the special allocated next header code point to account for BIER next header 0xAB37.

I honestly think the L2 should be removed from the BIERin6 draft so that the optional IPV6 encapsulation is no longer “optional” in the draft as that now is the draft.

This also provides the “IPv6 encapsulation” commonality with BIERv6 at least showing clearly that their is a strive for commonality and parity between the two solutions.

Also the “muddying” of the water is eliminated by removing L2 making the solution crystal clear to operators.

Kind Regards

Gyan

On Mon, Nov 23, 2020 at 7:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Thanks.
Jeffrey

Hi Jeffrey

In-line Gyan6>

Kind Regards

Gyan

Please see zzh6> below.

Hi Jeffrey

In line gyan4>

Hi Jeffrey

Excerpt from RFC 8296

IANA L2 scenario:

    Gyan6> Agreed.

   Registry.

   Registry.

In-line Gyan3>

Hi Jeffrey

Please see in-line below

Please see zzh3> below.

GS - Agree.

   Gyan3> Good point Agreed

Questions below.

Zzh4> Yes.

How would it work?

Zzh4> Yes

What is that solution?

Zzh4> Yes

Zzh4> Yes

Zzh4> See above.

Zzh4> Yes

Zzh6> No.

Zzh4> Please see above.

Hi Greg

In-line

Thanks

Thank you for your help.

     Gyan> Welcome

    Gyan> Understood.

   allocated by IANA.

GS - Thank you.

    Gyan> Welcome

GS - Agree.

Thanks,
Greg

Kind Regards

Gyan

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347
--

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

Gyan Mishra

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

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 25 Nov 2020 13:14:12 -0800

Dear All,
I apologize for jumping into this discussion but have someone said "OAM"? :)
I much appreciate what our co-chair (and contributor to BIER OAM) had to
say about the state of BIER OAM work. I agree with Tony's summary that our
joint efforts already created the toolset of the distinctive solutions for
BIER OAM. We've followed draft-ietf-bier-oam-requirements
<https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/> to
define the comprehensive set of OAM mechanisms that support proactive and
on-demand failure detection and localization using both BFD and echo
request/reply. Also, as Tony mentioned, we have drafts on path MTU
discovery in the BIER environment and application of the Alternate Marking
method for the packet delay and packet loss measurement in a BIER domain.
In my opinion, the section on OAM in draft-ietf-bier-ipv6-requirements is
helpful. I have a question on the intention of the following wording:

.... by specifying a new method for the same functionality.

If there's, for example, WG draft on proactive failure detection in the
BIER network using p2mp BFD with unsolicited notifications, why would we
entertain the idea of defining a new protocol or method for the same
purpose? I think that the ability to use BIER OAM solutions as defined in
their respective drafts already accepted by the WG (and some even passed
WGLC) is the litmus test for any proposed method of realizing BIER in IPv6
network. Thus I propose the following change of Section 3.1.4
<https://tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-09#section-3.1.4>
:
OLD TEXT:
   BIER OAM tools like [I-D.ietf-bier-ping] and [I-D.ietf-bier-pmmm-oam]
   should be supported, either directly using existing methods, or by
   specifying a new method for the same functionality.  They are likely
   to be needed in normal BIER deployment for diagnostics.
NEW TEXT:
   BIER OAM tools defined in WG document, for example,
   [I-D.ietf-bier-ping] and [I-D.ietf-bier-pmmm-oam],
   must be supported as defined in the respective specifications.
Consistency
   of OAM BIER tools is essential for the productive operation of BIER
networks.

Regards,
Greg

On Wed, Nov 18, 2020 at 11:09 PM Tony Przygienda <[email-masked]>
wrote:

>> modern

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 25 Nov 2020 16:46:00 -0500

Hi Greg

Much appreciated your jumping into the discussion and most welcome.

As Tony mentioned the OAM tight coupling to BIER architecture for P2MP
trees.

I will get the OAM section updated with the new text.

Kind Regards

Gyan

*Gyan Mishra*

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Nov 2020 13:11:30 -0000

I’ve been reading up on this thread and the three related drafts.

I don’t dip into BIER often (I’m not a multicast person, and I have a life), but this seemed to be a fairly weighty topic which has been bubbling away for a while, and the volume of the discussion suggested that this is a really important question (it sounded like a life and death decision judging by some of the emails!).

I think Tony captured some really key points in his email below. I particularly like his observation that BIER is working at the neck of the hourglass: that demands caution and good judgement; it also requires everyone to step back and do the right thing regardless of their investment (emotional or financial) in their preferred solution.

It seems to me (again, from the outside, and apologies if this is re-opening age-old discussions) that most of this is just protocol engineering. We have long experience at making any protocol do anything we want. If a particular solution lacks some capability, it can always be added with an extra TLV. That makes comparisons of solutions (also known as beauty contests) somewhat pointless: if you judge A better than B because B lacks some feature, then we just add the feature to B, and the cycle starts again.

That means that, while the requirements work is highly valuable for working out what the solution should deliver, it is not so helpful in determining which solution the WG should pursue. We are left, IMHO, with some of the edge requirements about transiting non-BIER nodes. These are nodes that can happily process “normal” IPv6 packets, but don’t know what to do with a BIER encapsulation. That looks like Section 3.1.3 of the requirements draft.

Embedded in that requirement is discussion of what an IPv6 router that is a transit might do with a packet. On the whole, routers just route on the fields in the v6 header itself, but they may look deeper in order to perform ECMP functions etc. For example, they may look for the transport payload to hash on ports etc. To achieve this, a router must be able to step over any additional headers (RH, DOH, etc.) to find the payload or must know not to even try. In general, a router that doesn’t understand a header will step over it if it can, but will probably give up the hunt for hashable fields. 

At this point I ran aground ☹ 8926 doesn’t have anything to say about ECMP in a BIER network (with or without BIER-capable routers). But 8279 has a nice fat section on ECMP, but this seems to describe how ECMP works when processing the BIER encapsulation for equal cost paths between BIER routers, not for how the “underlay” (the IPv6 network in this case) might handle equal cost paths in its own routing.

Any clues as to how ECMP is expected to work in the context of the v6 requirements? Anything that should be added to 3.1.3 or a new section?

Thanks,

Adrian

From: BIER <[email-masked]> On Behalf Of Tony Przygienda
Sent: 20 November 2020 05:36
To: Greg Shepherd <[email-masked]>
Cc: BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>; [email-masked] <[email-masked]>; Alvaro Retana <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Well, I’m glad that the work on requirements draft, albeit as product found wanting in AD’s assessment, has led to clarification of the crucial questions that e'one seems to agree need to be asked. 

It surprised me then mildly that my co-chair had to explicitly lay out the semantics of what was a clear direction spelled out during the meeting but that’s all well to get e’one better in sync I guess. Needless to say I am sharing his assessment and questions put to the room entirely. 

Some things that I think need explicit spelling out IMO after the last few meetings (since I’m not sure e’one in the process internalized that) is that WG is not here to tell people they cannot work on something whatever the perception seems to be, IETF doesn’t work that way. People go sideways and build stuff based on what we publish/develop in open source and for their customers in all kind of ways which may be neither fitting into an architecture, consensus or interest of a WG all the time. And that’s wonderful and more power to them, RFCs are free to download and they are just RFCs, they are not stone tablets brought from the mountain. However, and that's a big however, _if_ a work is looking for WG adoption and ultimately RFC status, the IETF process kicks in and the process has been here and well debugged over 30 years and that’s why Internet was built IME. The process is unusual in the way that it resists pretty well pressure based on non-technical claims, exceedingly poor architectural choices, chair shopping, padding of communication channels with “I participated only once to send a +1 to a list”, ad-hominem attacks and similar shenanigans that have been all tried over and over again. In the same vein the process tends to weigh based on reputation of “who said what in which context”'; such reputation being built on community service and sound work over many years. And sometimes hard calls are made based on rough consensus called by people that are here to steer stuff and nudge it along the way. Sure, it’s easy to standardize and build “something”, it’s very hard to keep it going operationally @ Internet scale for 20 years and lots of those lessons are unfortunately scar tissue not easily transferred except at level of RFC1925. Last point to emphasize is that BIER is not the average set of RFCs, we have been handed the permission to go into the hourglass of the Internet, something that happens every 15 years or so. The stuff we deliver is as fundamental as MPLS or IP forwarding plane and as PS has to meet toughest architectural standards to prevent a melt-down of non-orthogonal, under’spec’ed solutions leading to poor operational properties @ scale and non-interoperable solutions which long-term serves no'one well that relies on IP technology to support high quality infrastructure @ scale.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Nov 2020 15:24:43 +0000

Hi Adrian,

Looks like I don’t have a life – making arguments for this life and death situation on Thanksgiving day 😊

Anyway, about the ECMP topic, not sure if the following addresses your questions/comments.

At BIER layer itself, BIER packet has an entry field used for hashing to decide which ECMP path to the next BFR it will take. This is used by any BFR.

If BFR1 determines that for to reach BFR2 it is going to use tunnel1 (vs. tunnel2 or another L2 link), and tunnel1 is an IPv6 tunnel, then with BIERin6 an IPv6 header is put on by BFR1, with the BIER header following the IPv6 header, and the BIER header’s entropy field copied into IPv6 header’s flow label field. That flow label field is then used by the routers along the tunnel to do ECMP.

Jeffrey

From: BIER <[email-masked]> On Behalf Of Adrian Farrel
Sent: Thursday, November 26, 2020 8:12 AM
To: 'Tony Przygienda' <[email-masked]>; 'Greg Shepherd' <[email-masked]>
Cc: 'BIER WG' <[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Thanks,
Adrian

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Przygienda
Sent: 20 November 2020 05:36
To: Greg Shepherd <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; draft-ietf-bier-ipv6-requirements <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Alvaro Retana <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Nov 2020 16:24:10 -0000

Hi Jeffery,

Happy Thanksgiving!

Are you saying that all IPv6 routers use flow label and other primary header for entropy and none of them looks into the payload? (I’m asking cos I don’t know what v6 routers do.)

RFC 6437 implies that routers should use the “traditional” 5-tuple in addition to the flow label. But maybe routers don’t follow 6437?

BTW, I not trying to debate the solutions. I’m trying to find out what behavior is required in the IPv6 tunnel between BFRs. It appears that ECMP is required (good). Are we asking for any “special” ECMP behavior, or do we assume that the tunnel transit nodes are blind legacy nodes that cannot tell a BIER packet from any other packet?

Cheers,

Adrian

From: Jeffrey (Zhaohui) Zhang <[email-masked]> 
Sent: 26 November 2020 15:25
To: [email-masked]; 'Tony Przygienda' <[email-masked]>; 'Greg Shepherd' <[email-masked]>
Cc: 'BIER WG' <[email-masked]>
Subject: RE: [Bier] draft-ietf-bier-ipv6-requirements-09

Hi Adrian,

Jeffrey

From: BIER <[email-masked] <mailto:[email-masked]> > On Behalf Of Adrian Farrel
Sent: Thursday, November 26, 2020 8:12 AM
To: 'Tony Przygienda' <[email-masked] <mailto:[email-masked]> >; 'Greg Shepherd' <[email-masked] <mailto:[email-masked]> >
Cc: 'BIER WG' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Thanks,

Adrian

From: BIER <[email-masked] <mailto:[email-masked]> > On Behalf Of Tony Przygienda
Sent: 20 November 2020 05:36
To: Greg Shepherd <[email-masked] <mailto:[email-masked]> >
Cc: BIER WG <[email-masked] <mailto:[email-masked]> >; Gyan Mishra <[email-masked] <mailto:[email-masked]> >; draft-ietf-bier-ipv6-requirements <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> >; Alvaro Retana <[email-masked] <mailto:[email-masked]> >; Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 26 Nov 2020 09:37:38 -0800

Quickly chiming in only the address the possible budding confusion on ECMP

1. Adrian, yes, this is hourglass _L2.5_ and hence we have to consider lots
of things which can be hand-waived around in other groups. Things like OAM,
silicon speed/size/offsets/pipeline depth, ECMP that you're bringing up,
_transitory_ solutions to support jumping non-BIER routers until we have an
all native silicon everywhere are all important considerations.
2. ECMP in this case (i.e. encapsulation into v6 header) is NOT control
plane, it's a pure dataplane issue. In case of v6 _encapsulation_ we simply
need to support a _transitory_ encapsulation solution as Greg S. stated
repeatedly (and as footnote: and possibly very cheap silicon like WiFi
where it is desirable to allow any old v6 silicon to pick up a packet that
is BIER and throw it to middle path or slow path to support BIER e.g. as
homenet multicast solution. Speaking of which, maybe HomeNet should go into
requirements document, some noises were made years ago but basically
Homenet answer was, "well, we don't have multicast solution, PIM is
overkill, we probably should work on something". Newest state there escapes
me right now). Given BIER is L2.5 we basically encaps hop-by-hop and the
only ECMP issue here are possibly parallel links where BIER does NOT really
care about the outcome.  So whether we use Flow-ID field or Flow-ID + 5
tuple is really not that interesting but since in case of BIERin6 there is
no 5-tuple (it's just a next-header-protocol in v6 like UDP or whats-not)
that could use Flow-ID copied from BIER entropy for consistency reason and
give a good chance for different flows to use different _parallel_ one hop
links. Without silicon knowing anything about BIER or having to reach into
the packet @ deep offset to find entropy.
3. ECMP in BIER as control-plane is an issue which is irrelevant to
encapsulation since it only exists when looking @ end2end BIER forwarding
to a BFER. This is basically the whole discussion how to compute BIFTs with
the trade-offs going back to yours/Eric observations and my picture of the
fishtail when BIER architecture was discussed around 2014/15 or so. This
does not care about link specific encapsulation at all (which
MPLS/Ether/non-ether/BIERin6 encapsulations are).
4. The ECMP-v6 confusion may be related to the fact that given stuff is in
a v6 packet the temptation to throw packet multiple hops (violating the
specs even if we write them "you shall never do that" ;-) will be
irresistible. And yes, it's a viable _transitory_ solution that
architecture outlines to "jump over non-BIER routers via unicast tunnels".
But ECMP of this unicast tunnels is in a sense that's NOT BIER ECMP since
it will not process the mask so IPv6 can do what it wants in a sense.
Obviously OAM is lost when doing such kind of stuff and it is to observe
that architecture supports _transition_ shortcuts so any other technology
could be used like GRE, v6, IP, SRv6 tunnel here is just a random choice.
Now, however, and that confuses lots of people AFAIS, the perception by
some people rather new to BIER is that v6-encapsulation-work becomes all of
a sudden a charter to write a new multicast-L3 tunneling technology and
first, as Greg & others pointed out many times and they have huge amount of
years in multicast amongst them, that was has proven operationally quite
challenging and ultimately not very successul repeatedly (for manifold
reasons I don't want to spend lots time here) otherwise BIER would not have
happened AFAI.  And second if L3 multicast tunnel is really desired, mLDP,
PIM and other things exist since L3 multicast tunnel needs signalling, leaf
joins, dealing with ethernet multicast, state to pin the tunnels possibly,
specialized OAM and procedures etc, etc so if anything it seems to me like
a BoF, new WG matter calling it
"mLDP-or-something-hacked-to-use-BIER-bitmasks-and-somehow-magically-compress-flow-state"
but that's just random musings given BIER today is already a perfect mp2mp
PSMI that plugs in one-for-one-replacement into MVPN/EVPN with procedures
worked out in WG and about to go RFC. All that given that Ice was one of
the brainfathers/implementors of mLDP & hierarchical mLDP and ultimately,
after years of pain, was I think _the_ father of the basic BIER idea to
avoid all the problems that such a solution causes. Seeing BIER as "better
mLDP" is however also a wrorng way to think about it, BIER is an hourglass
technology independent of L3 as much as MPLS is.

PS: I personally still wait for the BIER(SR)v6 authors to address the
fundamental justification questions that Greg formulated in the working
group and were clarified on the mail independently of all those side
threads coming up now (most of them touching good issues though like MVPN
efficiency etc) that help to clarify the requirements.
PPS: I BTW do _strongly_ disapprove of some of the completely off-topic and
discourteous utterances by fairly fresh BIERv6 proponents on some of those
threads but I leave it to my co-chair and AD to deal with that.

thanks

-- tony

On Thu, Nov 26, 2020 at 8:24 AM Adrian Farrel <[email-masked]> wrote:

> Hi Jeffery,
>
>
>
> Happy Thanksgiving!
>
>
>
> Are you saying that all IPv6 routers use flow label and other primary
> header for entropy and none of them looks into the payload? (I’m asking cos
> I don’t know what v6 routers do.)
>
> RFC 6437 implies that routers should use the “traditional” 5-tuple in
> addition to the flow label. But maybe routers don’t follow 6437?
>
>
>
> BTW, I not trying to debate the solutions. I’m trying to find out what
> behavior is required in the IPv6 tunnel between BFRs. It appears that ECMP
> is required (good). Are we asking for any “special” ECMP behavior, or do we
> assume that the tunnel transit nodes are blind legacy nodes that cannot
> tell a BIER packet from any other packet?
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Sent:* 26 November 2020 15:25
> *To:* [email-masked]; 'Tony Przygienda' <[email-masked]>; 'Greg
> Shepherd' <[email-masked]>
> *Cc:* 'BIER WG' <[email-masked]>
> *Subject:* RE: [Bier] draft-ietf-bier-ipv6-requirements-09
>
>
>
> Hi Adrian,
>
>
>
> At BIER layer itself, BIER packet has an entry field used for hashing to
> decide which ECMP path to the next BFR it will take. This is used by any
> BFR.
>
>
>
> If BFR1 determines that for to reach BFR2 it is going to use tunnel1 (vs.
> tunnel2 or another L2 link), and tunnel1 is an IPv6 tunnel, then with
> BIERin6 an IPv6 header is put on by BFR1, with the BIER header following
> the IPv6 header, and the BIER header’s entropy field copied into IPv6
> header’s flow label field. That flow label field is then used by the
> routers along the tunnel to do ECMP.
>
>
>
> Jeffrey
>
>
>
> *From:* BIER <[email-masked]> *On Behalf Of *Adrian Farrel
> *Sent:* Thursday, November 26, 2020 8:12 AM
> *To:* 'Tony Przygienda' <[email-masked]>; 'Greg Shepherd' <
> [email-masked]>
> *Cc:* 'BIER WG' <[email-masked]>
> *Subject:* Re: [Bier] draft-ietf-bier-ipv6-requirements-09
>
>
>
> I don’t dip into BIER often (I’m not a multicast person, and I have a
> life), but this seemed to be a fairly weighty topic which has been bubbling
> away for a while, and the volume of the discussion suggested that this is a
> really important question (it sounded like a life and death decision
> judging by some of the emails!).
>
>
>
> I think Tony captured some really key points in his email below. I
> particularly like his observation that BIER is working at the neck of the
> hourglass: that demands caution and good judgement; it also requires
> everyone to step back and do the right thing regardless of their investment
> (emotional or financial) in their preferred solution.
>
>
>
> It seems to me (again, from the outside, and apologies if this is
> re-opening age-old discussions) that most of this is just protocol
> engineering. We have long experience at making any protocol do anything we
> want. If a particular solution lacks some capability, it can always be
> added with an extra TLV. That makes comparisons of solutions (also known as
> beauty contests) somewhat pointless: if you judge A better than B because B
> lacks some feature, then we just add the feature to B, and the cycle starts
> again.
>
>
>
> That means that, while the requirements work is highly valuable for
> working out what the solution should deliver, it is not so helpful in
> determining which solution the WG should pursue. We are left, IMHO, with
> some of the edge requirements about transiting non-BIER nodes. These are
> nodes that can happily process “normal” IPv6 packets, but don’t know what
> to do with a BIER encapsulation. That looks like Section 3.1.3 of the
> requirements draft.
>
>
>
> Embedded in that requirement is discussion of what an IPv6 router that is
> a transit might do with a packet. On the whole, routers just route on the
> fields in the v6 header itself, but they may look deeper in order to
> perform ECMP functions etc. For example, they may look for the transport
> payload to hash on ports etc. To achieve this, a router must be able to
> step over any additional headers (RH, DOH, etc.) to find the payload or
> must know not to even try. In general, a router that doesn’t understand a
> header will step over it if it can, but will probably give up the hunt for
> hashable fields.
>
>
>
> At this point I ran aground ☹ 8926 doesn’t have anything to say about
> ECMP in a BIER network (with or without BIER-capable routers). But 8279 has
> a nice fat section on ECMP, but this seems to describe how ECMP works when
> processing the BIER encapsulation for equal cost paths between BIER
> routers, not for how the “underlay” (the IPv6 network in this case) might
> handle equal cost paths in its own routing.
>
>
>
> Any clues as to how ECMP is expected to work in the context of the v6
> requirements? Anything that should be added to 3.1.3 or a new section?
>
>
>
> Thanks,
>
> Adrian
>
>
>
>
>
> *From:* BIER <[email-masked]> *On Behalf Of *Tony Przygienda
> *Sent:* 20 November 2020 05:36
> *To:* Greg Shepherd <[email-masked]>
> *Cc:* BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>;
> [email-masked]>; Alvaro Retana <[email-masked]>; Jeffrey
> (Zhaohui) Zhang <[email-masked]>
> *Subject:* Re: [Bier] draft-ietf-bier-ipv6-requirements-09
>
>
>
> Well, I’m glad that the work on requirements draft, albeit as product
> found wanting in AD’s assessment, has led to clarification of the crucial

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Nov 2020 18:43:51 -0000

Thanks Tony,

I’m going to assume that, despite the fact that I’m a fairly fresh person to this discussion, I don’t count as someone whose utterances (so far) have been discourteous. I’m certainly not supporting any specific solution.

The thing I pick out from your extensive reply is “packet the temptation to throw packet multiple hops (violating the specs even if we write them ‘you shall never do that’ ;-) will be irresistible.”

That leaves us with a choice:

*	Recognise that the irresistible will happen and factor it in
*	Determine that multi-hop IP is not supported and factor it out

“Factored in” means, of course, understanding that the v6-carrying-BIER packets must be able to pass through transit routers with as much functionality as possible.

“Factored out” means either not doing anything to support it, and not caring if it crashes and burns, or deliberately engineering that a legacy transit router would gracefully drop or reject the packets.

Cheers,

Adrian

From: Tony Przygienda <[email-masked]> 
Sent: 26 November 2020 17:38
To: Adrian Farrel <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; Greg Shepherd <[email-masked]>; BIER WG <[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

1. Adrian, yes, this is hourglass _L2.5_ and hence we have to consider lots of things which can be hand-waived around in other groups. Things like OAM, silicon speed/size/offsets/pipeline depth, ECMP that you're bringing up, _transitory_ solutions to support jumping non-BIER routers until we have an all native silicon everywhere are all important considerations. 

2. ECMP in this case (i.e. encapsulation into v6 header) is NOT control plane, it's a pure dataplane issue. In case of v6 _encapsulation_ we simply need to support a _transitory_ encapsulation solution as Greg S. stated repeatedly (and as footnote: and possibly very cheap silicon like WiFi where it is desirable to allow any old v6 silicon to pick up a packet that is BIER and throw it to middle path or slow path to support BIER e.g. as homenet multicast solution. Speaking of which, maybe HomeNet should go into requirements document, some noises were made years ago but basically Homenet answer was, "well, we don't have multicast solution, PIM is overkill, we probably should work on something". Newest state there escapes me right now). Given BIER is L2.5 we basically encaps hop-by-hop and the only ECMP issue here are possibly parallel links where BIER does NOT really care about the outcome.  So whether we use Flow-ID field or Flow-ID + 5 tuple is really not that interesting but since in case of BIERin6 there is no 5-tuple (it's just a next-header-protocol in v6 like UDP or whats-not) that could use Flow-ID copied from BIER entropy for consistency reason and give a good chance for different flows to use different _parallel_ one hop links. Without silicon knowing anything about BIER or having to reach into the packet @ deep offset to find entropy. 

3. ECMP in BIER as control-plane is an issue which is irrelevant to encapsulation since it only exists when looking @ end2end BIER forwarding to a BFER. This is basically the whole discussion how to compute BIFTs with the trade-offs going back to yours/Eric observations and my picture of the fishtail when BIER architecture was discussed around 2014/15 or so. This does not care about link specific encapsulation at all (which MPLS/Ether/non-ether/BIERin6 encapsulations are). 

4. The ECMP-v6 confusion may be related to the fact that given stuff is in a v6 packet the temptation to throw packet multiple hops (violating the specs even if we write them "you shall never do that" ;-) will be irresistible. And yes, it's a viable _transitory_ solution that architecture outlines to "jump over non-BIER routers via unicast tunnels". But ECMP of this unicast tunnels is in a sense that's NOT BIER ECMP since it will not process the mask so IPv6 can do what it wants in a sense. Obviously OAM is lost when doing such kind of stuff and it is to observe that architecture supports _transition_ shortcuts so any other technology could be used like GRE, v6, IP, SRv6 tunnel here is just a random choice. Now, however, and that confuses lots of people AFAIS, the perception by some people rather new to BIER is that v6-encapsulation-work becomes all of a sudden a charter to write a new multicast-L3 tunneling technology and first, as Greg & others pointed out many times and they have huge amount of years in multicast amongst them, that was has proven operationally quite challenging and ultimately not very successul repeatedly (for manifold reasons I don't want to spend lots time here) otherwise BIER would not have happened AFAI.  And second if L3 multicast tunnel is really desired, mLDP, PIM and other things exist since L3 multicast tunnel needs signalling, leaf joins, dealing with ethernet multicast, state to pin the tunnels possibly, specialized OAM and procedures etc, etc so if anything it seems to me like a BoF, new WG matter calling it "mLDP-or-something-hacked-to-use-BIER-bitmasks-and-somehow-magically-compress-flow-state" but that's just random musings given BIER today is already a perfect mp2mp PSMI that plugs in one-for-one-replacement into MVPN/EVPN with procedures worked out in WG and about to go RFC. All that given that Ice was one of the brainfathers/implementors of mLDP & hierarchical mLDP and ultimately, after years of pain, was I think _the_ father of the basic BIER idea to avoid all the problems that such a solution causes. Seeing BIER as "better mLDP" is however also a wrorng way to think about it, BIER is an hourglass technology independent of L3 as much as MPLS is. 

PS: I personally still wait for the BIER(SR)v6 authors to address the fundamental justification questions that Greg formulated in the working group and were clarified on the mail independently of all those side threads coming up now (most of them touching good issues though like MVPN efficiency etc) that help to clarify the requirements. 

PPS: I BTW do _strongly_ disapprove of some of the completely off-topic and discourteous utterances by fairly fresh BIERv6 proponents on some of those threads but I leave it to my co-chair and AD to deal with that. 

thanks

-- tony 

On Thu, Nov 26, 2020 at 8:24 AM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Hi Jeffery,

Happy Thanksgiving!

Cheers,

Adrian

From: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]> > 
Sent: 26 November 2020 15:25
To: [email-masked] <mailto:[email-masked]> ; 'Tony Przygienda' <[email-masked] <mailto:[email-masked]> >; 'Greg Shepherd' <[email-masked] <mailto:[email-masked]> >
Cc: 'BIER WG' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Bier] draft-ietf-bier-ipv6-requirements-09

Hi Adrian,

Jeffrey

Thanks,

Adrian

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 26 Nov 2020 23:37:44 +0000

Hi Adrian,

Please see zzh> below.

From: Adrian Farrel <[email-masked]>
Sent: Thursday, November 26, 2020 11:24 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; 'Tony Przygienda' <[email-masked]>; 'Greg Shepherd' <[email-masked]>
Cc: 'BIER WG' <[email-masked]>
Subject: RE: [Bier] draft-ietf-bier-ipv6-requirements-09

Hi Jeffery,

Happy Thanksgiving!

Zzh> Thanks!

Zzh> No. I just believe/assume the preferred/modern way going forward for ECMP is flow label based. The BIERv6 proponents are emphasizing on “modern” aspect of that solution, too 😊

Zzh> I assume that is only applicable for the typical TCP/UDP payload, and not enough for today’s multi-service networks?

Zzh> Understand. Technical discussions are always appreciated, even if it is for debating the solutions. The chairs once requested that the requirements draft does not evaluate solutions, but we can certainly evaluate outside the draft.

Zzh> Tunnel transit nodes may not understand BIER at all, but with BIERin6 they should not mistake a BIER packet as an IP packet, as the first nibble of the BIER header is set to 0101 (would be “IPv5” if one treat it as IP version). This would then be similar to PW ECMP (where a CW with first nibble of 0000 is used).
Zzh> With BIERv6, even though the BIER payload follows the IPv6 header directly, the “traditional” 5-tuple based ECMP may not be used after all for two reasons: 1. The payload may not be IP 2. It seems that to locate the start of real payload (after the extension headers) for ECMP hashing, a router will need to follow the chain of extension headers one by one (since the standard IPv6 header does not have a field for the total length of all headers) and a legacy transit router may not actually do that for implementation/performance reasons.
Zzh> Even if a legacy transit router actually follows the extension headers to do 5-tuple based ECMP, since the BIERv6 proponents emphasizes on the “modern” technology/direction, it would be reasonable to consider the ECMP issue in the context of flow label based solution.
Zzh> Thanks.
Zzh> Jeffrey

Cheers,
Adrian

From: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Sent: 26 November 2020 15:25
To: [email-masked]<mailto:[email-masked]>; 'Tony Przygienda' <[email-masked]<mailto:[email-masked]>>; 'Greg Shepherd' <[email-masked]<mailto:[email-masked]>>
Cc: 'BIER WG' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] draft-ietf-bier-ipv6-requirements-09

Hi Adrian,

Jeffrey

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
Sent: Thursday, November 26, 2020 8:12 AM
To: 'Tony Przygienda' <[email-masked]<mailto:[email-masked]>>; 'Greg Shepherd' <[email-masked]<mailto:[email-masked]>>
Cc: 'BIER WG' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Nov 2020 23:53:02 -0000

Thanks Jeffery,

I think our discussion forks.

In one direction Tony says (possibly) don’t worry about legacy transit routers because we shouldn’t be tunneling through them anyway.

In the other direction we worry about legacy routers, and here you are suggesting we should hope that they are legacy-but-modern 😉 That doesn’t seem to work out for us because *if* we need to tunnel through non-BIER routers we should probably assume that they might be old enough to not be considered modern.

I do like your answer that if the BIER header is encountered as payload it will not be hashed because of the first nibble. I’d missed that and it handles the case of native encapsulation.

But I think that even legacy IPv6 routers that do ECMP are capable of walking the extension headers until they find a header that is a known protocol or until they find one they can’t parse. (But I may be wrong here.)

Now, we have got diverted (again) into discussions of what we can and can’t do with different solutions. We need to come back to the requirement:

Do we need to be able to tunnel through legacy routers? I am sure I hear Tony saying “no, that is explicitly excluded”.

If the answer is “no”, let’s capture that in the requirements doc.

If the answer is “yes” then we have a second question…

Do we need to provide ECMP in that tunnel?

If the answer to that is “no”, we’re done.

But if the answer here is “yes”, we have to ask…

Is it enough to rely on the flow label (and src/dst), or do other fields need to be available.

Cheers,

Adrian

Sent: 26 November 2020 23:38

Hi Adrian,

Please see zzh> below.

From: Adrian Farrel <[email-masked] <mailto:[email-masked]> > 
Sent: Thursday, November 26, 2020 11:24 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]> >; 'Tony Przygienda' <[email-masked] <mailto:[email-masked]> >; 'Greg Shepherd' <[email-masked] <mailto:[email-masked]> >
Cc: 'BIER WG' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Bier] draft-ietf-bier-ipv6-requirements-09

Hi Jeffery,

Happy Thanksgiving!

Zzh> Thanks!

Zzh> Thanks.

Zzh> Jeffrey

Cheers,

Adrian

Hi Adrian,

Jeffrey

Thanks,

Adrian

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 26 Nov 2020 17:06:09 -0800

On Thu, Nov 26, 2020 at 10:43 AM Adrian Farrel <[email-masked]> wrote:

> Thanks Tony,
>
>
>
> I’m going to assume that, despite the fact that I’m a fairly fresh person
> to this discussion, I don’t count as someone whose utterances (so far) have
> been discourteous. I’m certainly not supporting any specific solution.
>

absolutely not, the guilty parties know who they are :-/

>
> The thing I pick out from your extensive reply is “packet the temptation
> to throw packet multiple hops (violating the specs even if we write them
> ‘you shall never do that’ ;-) will be irresistible.”
>
>
>

well, people will ;-) and we have to talk about it as I said

>    - Recognise that the irresistible will happen and factor it in
>
>
yepp

>
>    -
>    - Determine that multi-hop IP is not supported and factor it out
>
> “Factored in” means, of course, understanding that the v6-carrying-BIER
> packets must be able to pass through transit routers with as much
> functionality as possible.
>
> “Factored out” means either not doing anything to support it, and not
> caring if it crashes and burns, or deliberately engineering that a legacy
> transit router would gracefully drop or reject the packets.
>
>
>
well, "as much functionality" is debatable, "it must pass by the routers"
is not

thanks, Adrian, good take

-- tony

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 26 Nov 2020 17:10:34 -0800

<as individual>

On Thu, Nov 26, 2020 at 3:53 PM Adrian Farrel <[email-masked]> wrote:

> In one direction Tony says (possibly) don’t worry about legacy transit
> routers because we shouldn’t be tunneling through them anyway.
>
> In the other direction we worry about legacy routers, and here you are
> suggesting we should hope that they are legacy-but-modern 😉 That doesn’t
> seem to work out for us because **if** we need to tunnel through non-BIER
> routers we should probably assume that they might be old enough to not be
> considered modern.
>
>
>
> I do like your answer that if the BIER header is encountered as payload it
> will not be hashed because of the first nibble. I’d missed that and it
> handles the case of native encapsulation.
>
>
>
> But I think that even legacy IPv6 routers that do ECMP are capable of
> walking the extension headers until they find a header that is a known
> protocol or until they find one they can’t parse. (But I may be wrong here.)
>
>
>
> Now, we have got diverted (again) into discussions of what we can and
> can’t do with different solutions. We need to come back to the requirement:
>
>
>
> Do we need to be able to tunnel through legacy routers? I am sure I hear
> Tony saying “no, that is explicitly excluded”.
>

I wish we couldn't but reality will be, people will throw tunnels multiple
hops (and architecture allows that to deal with non-BIER HW inbetween)

> Do we need to provide ECMP in that tunnel?

well, it's IPv6 ECMP so who are we to argue how they do it. We should od
the best we can to support v6 ECMP AFAIS but we don't have in BIER anything
predictable but entropy field.

> Is it enough to rely on the flow label (and src/dst), or do other fields

right, so what's your take here? BIER doesn't offer anything except an
entropy field and that's what we can provide. encaps'ing it in UDP just
oget 5 tuple sounds desperate and pretty dirty (think vxlan) and what
happens if we carry native ETHER or MPLS inside, parsing into the BIER
paylod to figure out WHAT protocol is carried (v4, mpls or so) and then
into that is possible but sounds like a really, really, really deep silicon
lookup

what you're aiming at, Adrian?

-=-- tony

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 27 Nov 2020 14:13:30 -0000

Summarising…

1.	You wish we didn’t have to support tunneling over multiple IPv6 hops, but you think it’s going to happen so be better factor it.
We should capture that explicitly in the requirements doc.
2.	Given 1, we have no control over what happens in the IPv6 network. We should probably try not to do anything that encumbers “normal” IPv6 operation. That includes ECMP (but probably other things).

I’m *really* trying to stay away from discussing the solutions and the consequences. But..  :-Z

We can take two approaches to ECMP…

a.	Flow label and other primary fields are enough. Any attempt to look deeper into the packet is not necessary and if the router doesn’t understand the next header type it doesn’t matter.
b.	Where the payload is IP, Ethernet, or an IETF transport protocol, the router should be able to access it to improve the ECMP hashing.

Now, that leads me to a solution-oriented conclusion, but I’m not going to voice it. Let’s stick to the requirements.

Cheers,

Adrian

Sent: 27 November 2020 01:11

<as individual> 

On Thu, Nov 26, 2020 at 3:53 PM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Thanks Jeffery,

I wish we couldn't but reality will be, people will throw tunnels multiple hops (and architecture allows that to deal with non-BIER HW inbetween)

well, it's IPv6 ECMP so who are we to argue how they do it. We should od the best we can to support v6 ECMP AFAIS but we don't have in BIER anything predictable but entropy field. 

right, so what's your take here? BIER doesn't offer anything except an entropy field and that's what we can provide. encaps'ing it in UDP just oget 5 tuple sounds desperate and pretty dirty (think vxlan) and what happens if we carry native ETHER or MPLS inside, parsing into the BIER paylod to figure out WHAT protocol is carried (v4, mpls or so) and then into that is possible but sounds like a really, really, really deep silicon lookup 

-=-- tony

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 27 Nov 2020 14:45:14 +0000

Hi Adrian,

Please see zzh> below.

From: Adrian Farrel <[email-masked]>
Sent: Friday, November 27, 2020 9:14 AM
To: 'Tony Przygienda' <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; 'Greg Shepherd' <[email-masked]>; 'BIER WG' <[email-masked]>
Subject: RE: [Bier] draft-ietf-bier-ipv6-requirements-09

Summarising…

  1.  Flow label and other primary fields are enough. Any attempt to look deeper into the packet is not necessary and if the router doesn’t understand the next header type it doesn’t matter.
  2.  Where the payload is IP, Ethernet, or an IETF transport protocol, the router should be able to access it to improve the ECMP hashing.

Zzh> The requirements draft will not discuss/evaluate solutions, but outside the draft, I won’t be shy to voice my opinion 😊
Zzh> Going forward, flow label based ECMP should be the norm. If an existing solution1 can do b), great but it’s not too bad if it can’t do b). If we’re designing a new solution2 that can do b) but introduces other complexities while the existing solution1 does not have those complexities, then I would still prefer solution1.
Zzh> Jeffrey

Cheers,
Adrian

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Sent: 27 November 2020 01:11
To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Greg Shepherd <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

<as individual>

On Thu, Nov 26, 2020 at 3:53 PM Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Jeffery,

-=-- tony

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 27 Nov 2020 06:46:50 -0800

Thank you Jeffrey and Gyan for sticking with the thread of the conversation
to advance the discussion. It's clear now that all of the
requirements discussed so far can be addressed by the BIERin6 draft if we
flesh out the discussed gaps.

I would like to see Jeffrey and Gyan take over as primary authors of
BIERin6 to include the gaps discussed here so that it fully encompases the
requirements so far described, for WG adoption.

Thanks,
Shep

On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XDtgJDx3AuPsLEtWKNmJ-cMzKAtNsX_Xv7rPTyfejS7pxF9pMO9IQdFUWmsx5114$>
>
> *Gyan Mishra*
>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Sat, 28 Nov 2020 02:05:51 +0000

Hi Greg,

I have followed the thread. And I don't there is consensus about BIER IPv6 requirement and BIERin6 in WG. Here are some my concerns that have been discussed in IETF109:
1. Why we need a new "next header" when the existing IPv6 extension header could satisfy the BIER IPv6 requirement;
2. The comments raised by 6MAN WG and INT area are not addressed, which requests the document to be discussed in transport area;
3. BIERin6 is not an independent solution which uses BIER Ethernet when BFR nodes are connected directly.

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]] 
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thank you Jeffrey and Gyan for sticking with the thread of the conversation to advance the discussion. It's clear now that all of the requirements discussed so far can be addressed by the BIERin6 draft if we flesh out the discussed gaps.

I would like to see Jeffrey and Gyan take over as primary authors of
BIERin6 to include the gaps discussed here so that it fully encompases the requirements so far described, for WG adoption.

Thanks,
Shep

On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Now there are two lingering points alluded to in this thread, but 
> given it’s been such a long and deeply nested tread, I’ll start a new 
> thread about it.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> During the discussions I did mention that maybe in BIERin6 optional 
> IPv6 tunneling should be removed, as it seemed to create some 
> confusion, but now I am clear and as both the L2/tunnel and IPv6 
> L3/tunnel encapsulation single hop or multi hop tunnel both have the 
> clean BIER layering and complement each other I agree they belong together in the same draft.
>
> Even though L2/tunnel exists today as part of RFC8296 it makes sense 
> to be part of the overall BIERin6 solution.
>
>
>
> Overall throughout the discussions I agree that BIERin6 IPV6 tunnel 
> option and BIERv6 are not transitional and are long term solutions and 
> there are reasons why that we can add to the requirements draft as to 
> why IPV6 encapsulation is necessary below:
>
>
>
> This has been a very informative exchange and extremely helpful for 
> all of us to get onto the same page from a basic understanding POV.
>
>
>
> From your answers below it cannot work as we need two IANA code point 
> one for IPv6 next header type and ICMPv6.
>
>
>
> points if IPv6 tunneling is used for either getting over non-BFRs or 
> for FRR. One may deem non-BFR as a short-term scenario but FRR will be 
> here for the long run.
>
>
>
>     Gyan4>I am a little confused here with the code points.  For 
> BIERin6 “L2” BIER scenario RFC 8296 Non MPLS BIER Ethernet Ether type 0xAB37.
>
>
>
> Zzh6> Note that IPv6 header is not needed – it should be Ethernet 
> Zzh6> -0xAB37
> header may be inserted between BIER and payload, only for the SRv6 
> style VPN purpose.
>
> Gyan> Understood
>
> layer in an IPV6 environment and  IPv6 or ICMPv6 encapsulation and the 
> need for the next header code point above is the packet format:
>
>
>
> Excerpt from RFC 8296
>
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc5332__;!!NE
> t6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ84s
> sHlj$>].  IEEE
>
> So below is for both cases IANA code point allocation for “L2” next 
> header where next header is IPv6 or ICMPV6, and then the optional IPv6 
> Zzh6> I don’t follow what you’re talking about. If BIER header follows 
> Zzh6> L2
> header directly, no new code point is needed. It’s just “Ethernet 
> 0xAB37 | BIER | payload”.
>
>
>
>     Gyan6> Agreed.
>
>
>
> Zzh6> If IPv6 encapsulation is used, either on between directly 
> Zzh6> connected
> BFRs or indirectly connected BFRs, a new “next header” code point is 
> needed for BIER.
>
>  Gyan6>Understood
>
>
> 5
> My point is that the IANA allocation is different as the next header 
> is different for the L2 scenario where next header is IPv6 or ICMPV6, 
> and IPv6 encapsulation scenario where the next header is BIER.
>
>
>
> Zzh6> If BIER header follows L2 header directly, BIER Ethertype is 
> Zzh6> used
> (assuming Ethernet is the L2).
>
>  Gyan>Understood
>
> Based on this point I am making could we just do a RFC8296 bis version 
> and add the IANA code points for IPv6 and ICMPv6.
>
>
>
> Zzh6> Given the confusion/contention that have happened in the last 
> Zzh6> two
> though it already exists made sense to bundle into BIERin6 total solution

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 28 Nov 2020 03:31:42 +0000

Xuesong,

Please see zzh> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 9:06 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

Zzh> which existing IPv6 extension header? I hope it's not the DOH that encodes the BIER header as in BIERv6.
Zzh> Otherwise, the questions should be flipped around - since RFC8296 BIER over L2/tunnel works well (with just a new "next header" code point in case of IPv6 tunnel), why we need BIERv6?

Zzh> I am surprised to hear this brought up in this BIER session. I must have missed it in last IETF's 6man session. As we briefly talked about in this BIER session, it's strange that tunneling needs to be discussed in transport area, but I will dig into last 6man session's minutes and recording and report back.

Zzh> As have been repeated several times in recent threads, BIERin6 is about supporting BIER in IPv6 networks - it is appropriate and have become critical  given ongoing contention to have a spec to explicitly talk about how existing BIER over L2/tunnel can work nicely in an IPv6 network. With that, the above comment just does not make sense.
Zzh> Jeffrey

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]]
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thanks,
Shep

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Sat, 28 Nov 2020 03:57:24 +0000

Hi Jeffery, 

Please find the comments inline.

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Saturday, November 28, 2020 11:32 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Xuesong,

Please see zzh> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 9:06 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

【Xuesong】The answer is quite straight forward, because there is no extension header in Ethernet. IPv6 uses extension header for new functions/information. Based on the logic of BIERin6, some new next header code point should be allocated for Fragment Header, Authentication header and any functions that are supposed to be initiated with IPv6, which obviously violating RFC8200. 

【Xuesong】(It's interesting that BIERin6 authors brought the document to 6man in IETF 108 and received some comments but now I'm asked why it should be and what the comments are) please find the detailed discussion in https://www.youtube.com/watch?v=_1MFLec7pSw and the minutes could be found in https://datatracker.ietf.org/meeting/108/materials/minutes-108-6man-05.html .

【Xuesong】I can't see why some solution is appropriate when it depends on other solutions. It seems like in an IPv6 network with other type of L2 link except for Ethernet, BIERin6 doesn't work.

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]]
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thanks,
Shep

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 28 Nov 2020 04:01:53 +0000

Hi Xuesong,

I'll get back on the 6man's comments, but for the other two points, I have to say that you have not really understood BIERin6, or the basic concept of BIER over L2/tunnel.

Jeffrey

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 10:57 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffery,

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Saturday, November 28, 2020 11:32 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Xuesong,

Please see zzh> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 9:06 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

【Xuesong】(It's interesting that BIERin6 authors brought the document to 6man in IETF 108 and received some comments but now I'm asked why it should be and what the comments are) please find the detailed discussion in https://urldefense.com/v3/__https://www.youtube.com/watch?v=_1MFLec7pSw__;!!NEt6yMaO-gk!TUCt_gogUCdssS5rDQb5S00pjbJzddnbLVDKBxLUbbXHgSchHxhcsmJxXs-bW94t$  and the minutes could be found in https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/108/materials/minutes-108-6man-05.html__;!!NEt6yMaO-gk!TUCt_gogUCdssS5rDQb5S00pjbJzddnbLVDKBxLUbbXHgSchHxhcsmJxXgxXw2LK$  .

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]]
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thanks,
Shep

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Sat, 28 Nov 2020 06:27:09 +0000

Hi Jeffrey,

My point is quite simple: if there is extension capability in the protocol, use it; if there is not, make a tunnel over it. And IPv6 belongs to the first and Ethernet belongs to the second.
Even in BIER MPLS, BIER-MPLS label is newly defined to indicate BIFT-ID, using the scalability of MPLS. In IPv6, we use extension header.
BIER is not totally "transport independent", otherwise, there is no need to distinguish BIER in MPLS and BIER in non-MPLS in RFC8296.

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Saturday, November 28, 2020 12:02 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Xuesong,

Jeffrey

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 10:57 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffery,

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Saturday, November 28, 2020 11:32 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Xuesong,

Please see zzh> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 9:06 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]]
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thanks,
Shep

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 28 Nov 2020 14:22:03 +0000

Hi Xuesong,

Please see zzh2> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Saturday, November 28, 2020 1:27 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffrey,

Zzh2> I bet people will disagree "Ethernet does not have extension capability in the protocol".
Zzh2> Any L2/tunnel protocol has extension capability to indicate the payload type - Ethernet or PPP (for the POS example that Jingrong provided) or others (perhaps I could add "modern L2/tunnel" to be safe 😊). For a non-Ethernet L2, adding a new code point in the L2 header (or IPv6 header when tunnel is used) to indicate that a BIER header follows is using the "extension capability in the protocol".
Zzh2> BTW, MPLS also has capability to indicate payload type - by assigning payload-dependent labels - but that's a side point.

Zzh2> The BIER-MPLS and BIER non-MPLS is actually a *perfect* example of "transport independence" - the same BIER header and forwarding (including overlay forwarding in case of BIERin6) are used whether it is over L2, over MPLS tunnel, or over any tunnel.
Zzh2> If you know the early history of BIER, you will understand how/why BIER-MPLS was designed that way, and in fact, that same design concept is inherited by BIER-non-MPLS. The only difference between BIER-MPLS and BIER-non-MPLS is whether the BIFT-id is treated as a label or not (ok plus that in case of MPLS, the BIER label also indicates that a BIER header follows while BIER-non-MPLS requires a code point in the outer L2/tunnel header).
Zzh2> Jeffrey

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Saturday, November 28, 2020 12:02 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Xuesong,

Jeffrey

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 10:57 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffery,

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Saturday, November 28, 2020 11:32 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Xuesong,

Please see zzh> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 9:06 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]]
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thanks,
Shep

---

From: Michael McBride <[email-masked]>
Date: Sat, 28 Nov 2020 19:15:01 +0000

Hi Greg,

>Thank you Jeffrey and Gyan for sticking with the thread of the conversation to advance the discussion. It's clear now that all of the requirements >discussed so far can be addressed by the BIERin6 draft if we flesh out the discussed gaps.

>BIERin6 to include the gaps discussed here so that it fully encompases the requirements so far described, for WG adoption.

I'm sure I'm misinterpreting. What it sounds like you are saying is "I want bierin6 to be adopted so let's fix the gaps so we can begin". Since both solutions meet the requirements, I'm hoping you meant "Let's fix the gaps in bierin6 so we can begin adoption calls for both bierv6 and bierin6". 

mike

On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
> defense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!!
> NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8
> 4ssHlj%24&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a34
> 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8EiHsMns5Jut
> 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&amp;reserved=0>].  IEEE
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-zhang-bier-bierin6-07*section-5__%3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH%24&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a3414dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0%3D&amp;reserved=0>.
> IANA Considerations
>
>
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 28 Nov 2020 14:39:56 -0500

Hi Greg

Please respond to Mike’s email so that all authors and everyone in the WG
has a clear understanding of next steps.

Kind Regards

Gyan

On Sat, Nov 28, 2020 at 2:15 PM Michael McBride <
[email-masked]> wrote:

> Hi Greg,
>
> >Thank you Jeffrey and Gyan for sticking with the thread of the
> conversation to advance the discussion. It's clear now that all of the
> requirements >discussed so far can be addressed by the BIERin6 draft if we
> >BIERin6 to include the gaps discussed here so that it fully encompases
> the requirements so far described, for WG adoption.
>
> I'm sure I'm misinterpreting. What it sounds like you are saying is "I
> want bierin6 to be adopted so let's fix the gaps so we can begin". Since
> both solutions meet the requirements, I'm hoping you meant "Let's fix the
> gaps in bierin6 so we can begin adoption calls for both bierv6 and
> bierin6".
>
> mike
>
>
> > <
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-zhang-bier-bierin6-07*section-5__%3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH%24&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a3414dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0%3D&amp;reserved=0
> >.
> > IANA Considerations
> >
> >
> >
> >
> >
-- 

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 28 Nov 2020 21:53:41 +0000

To clarify, there is no gap in the BIERin6 solution (besides the new "next header" code point). It's just that some text are needed to explain how the requirements are met with the BIERin6 solution - whether it is a requirement already listed in the current requirements draft, or have been brought up in recent mailing list discussions (I know of two in recent discussions).

BIERin6 is based on RFC 8296 (plus the new "next header" code point for IPv6 encapsulation), and is a generic solution with the following properties:

1. clean layering - BIER over L2/tunnel and it can carry different payload types including SRv6
2. IPv4/IPv6 independent (of course you need different signaling)
3. L2 independent - as long as the L2 header can indicate with a code point that a BIER header follows
4. tunnel type independent - as long as the tunnel header can indicate with a code point that a BIER header follows
5. can work one-hop or multi-hop tunnels nicely
6. can work with SRv6 based services nicely

With the above, there is simply no need for another solution in my view. Of course the WG can continue discussing BIERv6 and may determine that it is nice to have BIERv6 as well, but we should not bundle them together when it comes to adoption. That's why I suggested in the last BIER session the following:

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <[email-masked]>
Sent: Saturday, November 28, 2020 2:15 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

mike

On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outloo
> k.com/?url=https*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp
> u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$
> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&amp;data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$ >.
> IANA Considerations
>
>
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 29 Nov 2020 01:43:56 -0500

Mike / All

As Jeffrey mentioned over the course of this detailed thread I flushed out
the understanding of BIERin6 and confirmed they no gaps exist.

As it stands today no changes related to the last contested item related to
“RFC 8296 L2 Ethernet” between myself and Jeffrey would change as the
BIERin6 draft as Jeffery has stated is an complete holistic solution for an
IPV6 environment.  This is a new development as I worked out in my mind per
below why L2 should be part of BIERin6 draft.

In order for BIERin6 draft to be holistic solution all encompassing of
requirements, it is required to have the existing RFC 8296 Non MPLS BIER
Ethernet with next header defined for BIER header 0xAB37, followed IPv6
payload, be part of the overall solution  - - this would used as the
primary solution for directly and non directly connected BFRs and the
“optional” solution would be BIERin6 which requires new next header for
BIER header following IPv6 encapsulation header and ICMP code point.  The
optional BIERin6 would be used in cases where the operator requires IPv6
tunneling or FRR.

As Jeffrey mentioned there is some text verbiage to be updated pertaining
to how the requirements are being met with BIERin6 solution.

Based on what Greg and Jeffrey have stated and my thorough review of
BIERin6 on ML I am in agreement that no gaps exist and that we just have to
ensure all verbiage is updated related to meeting any new or existing
requirements that maybe missing.

The key here in context  related to the requirements draft, BIERin6 will
satisfy all existing and any new requirements added to the draft, however
BIERin6 advancement is not dependent on the requirements draft.

The main reason for that is that the BIERin6 draft leverages existing
L2/tunnel RFC 8296 solution “Non MPLS BIER Ethernet” solution as the
primary solution for IPv6 environments.  The existing layering utilized in
Non MPLS BIER Ethernet is utilized in BIERin6 solution moving the BIER
header to inner header inside outer IPv6 header with identical layering
solution.

As BIERin6 IPv6 encapsulation solution utilizes the identical layering
style framework in essence by incorporating the existing L2 solution, it
makes the both solutions both homogeneous as well as holistic solution by
providing layering parity between the two solutions.  Another important
reason why the existing L2 solution should be part of the BIERin6 draft.

As the requirements draft is independent of the BIERin6 draft it can and
should be finalized.  The work on the requirements draft is pertinent to
the BIERv6 solution and should continue.

Once BIERin6 is adopted we would need to determine what gaps exist with
BIERin6 that can be satisfied by BIERv6 and identify.

If we are able to clearly identify those BIERin6 gaps that BIERv6 meets and
fills those gaps, as well as  all the requirements are met then we can seek
WG adoption of BIERv6 draft  as well.

Kind Regards

Gyan

On Sat, Nov 28, 2020 at 4:53 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> To clarify, there is no gap in the BIERin6 solution (besides the new "next
> header" code point). It's just that some text are needed to explain how the
> requirements are met with the BIERin6 solution - whether it is a
> requirement already listed in the current requirements draft, or have been
> brought up in recent mailing list discussions (I know of two in recent
> discussions).
>
> BIERin6 is based on RFC 8296 (plus the new "next header" code point for
> IPv6 encapsulation), and is a generic solution with the following
> properties:
>
> 4. tunnel type independent - as long as the tunnel header can indicate
> with a code point that a BIER header follows
> With the above, there is simply no need for another solution in my view.
> Of course the WG can continue discussing BIERv6 and may determine that it
> is nice to have BIERv6 as well, but we should not bundle them together when
> it comes to adoption. That's why I suggested in the last BIER session the
> following:
>
> - Adopt BIERin6
> - Discuss BIERv6 further
>
> Jeffrey
>
> Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <
> [email-masked]>; BIER WG <[email-masked]>;
> gaps in bierin6 so we can begin adoption calls for both bierv6 and bierin6".
>
> mike
>
>
> https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&amp;data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$
> >.
> > IANA Considerations
> >
> >
> >
> >
> >
-- 

*Gyan Mishra*

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Sun, 29 Nov 2020 10:58:33 +0000

Hi Jeffrey,

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Saturday, November 28, 2020 10:22 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Xuesong,

Please see zzh2> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Saturday, November 28, 2020 1:27 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffrey,

【Xuesong】Let's properly distinguish between "a protocol's ability to extend itself " and a protocol's ability to "support a new upper layer". 
In the hierarchical architecture of the Internet, each layer of protocol has the capability to indicate what the next protocol is supposed to be. A new code point is not for Ethernet extension, it is for new type of the payload or overlay protocols.
To be safe, please allow me to put it more accurately: Ethernet has the capability of extension but IETF is not the right place to do it 😊. So, in order to make BIER work over Ethernet, a L2 tunnel is defined in RFC8296.

【Xuesong】The BIER-MPLS and BIER non-MPLS is actually a perfect example of BIER is "not" transport independence. I don't think it's even necessary to say more, because we could get this conclusion by the name itself: BIER encapsulation is different when it is in a MPLS domain or a non-MPLS domain. 
Even if BIER-MPLS label is used only for indicating the next header, it will make more sense to claim that BIER MPLS is transport independence. But, BIER-MPLS label is used to indicate BIFT-id. It's encoding BIER information in a manner of MPLS, just like what we are trying to do with IPv6 extension header. I can't see why a new MPLS label for BIER is allowed but a new IPv6 extension header for BIER is denied, unless BIER WG has some special preference for MPLS.

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Saturday, November 28, 2020 12:02 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Xuesong,

Jeffrey

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 10:57 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffery,

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Saturday, November 28, 2020 11:32 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Xuesong,

Please see zzh> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 9:06 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]]
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thanks,
Shep

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Sun, 29 Nov 2020 11:11:49 +0000

"
- Adopt BIERin6
- Discuss BIERv6 further
"

I will leave all the technical issues for BIERin6 in another thread to make the discussion coherent. But I can't see the process mentioned above makes any sense. All the optional solutions are supposed to be evaluated on the same footing. If both technically practical and meet all the requirements, both should be accepted. Besides the technical considerations mentioned above, I believe there should not be any other factors that interfere with the WG process.

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Sunday, November 29, 2020 5:54 AM
To: Michael McBride <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

1. clean layering - BIER over L2/tunnel and it can carry different payload types including SRv6 2. IPv4/IPv6 independent (of course you need different signaling) 3. L2 independent - as long as the L2 header can indicate with a code point that a BIER header follows 4. tunnel type independent - as long as the tunnel header can indicate with a code point that a BIER header follows 5. can work one-hop or multi-hop tunnels nicely 6. can work with SRv6 based services nicely

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <[email-masked]>
Sent: Saturday, November 28, 2020 2:15 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

mike

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 29 Nov 2020 14:28:11 +0000

Hi Xuesong,

BIERin6 is just a small organic growth of RFC8296 - only a new IP "next header" code point is needed for the BIER layer (which BIERin6 is about). When it comes to overlay, no forwarding plane change is needed though if SRv6 is used for MVPN/EVPN, then some new *overlay* signaling is needed (and we'll submit a separate draft on that), but that's only in the overlay control plane, and only because of SRv6 as a new way to identify VPNs.

BIERv6 is more than that and does warrant more discussion at BIER/IPv6/overlay forwarding planes.

As such, BIERin6 should not be blocked by BIERv6.

Thanks.
Jeffrey

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Sunday, November 29, 2020 6:12 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Michael McBride <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

"
- Adopt BIERin6
- Discuss BIERv6 further
"

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Sunday, November 29, 2020 5:54 AM
To: Michael McBride <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <[email-masked]>
Sent: Saturday, November 28, 2020 2:15 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

mike

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 29 Nov 2020 15:02:39 +0000

Hi Xuesong,

Please see zzh3> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Sunday, November 29, 2020 5:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffrey,

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Saturday, November 28, 2020 10:22 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Xuesong,

Please see zzh2> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Saturday, November 28, 2020 1:27 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffrey,

Zzh3> "in order to make BIER work over Ethernet, a L2 tunnel is defined in RFC8296" - that is simply not true.
Zzh3> BIER non-MPLS over Ethernet does *not* use L2 tunnel. BIER header directly follows  Ethernet header, and we got an Ethertype 0xAB37 assigned for BIER.
Zzh3> In case of BIER over MPLS over Ethernet, that BIER label is not for a *tunnel*. That single label, which is not for the purpose of getting a packet from BFR1 to BFR2, serves the combined purpose of (0xAB37 + BIFT-id) in the case of BIER no-MPLS over Ethernet directly. If BFR1 and BFR2 are not directly connected, then a tunnel (L2, L2.5, or L3) tunnel is indeed needed, and that's still RFC8296 solution.

Zzh3> Now we have totally opposite views so I will defer that to other BIER veterans.

Zzh3> The history is as following:
Zzh3> 1. BIER WG designed BIER-MPLS first and intentionally mandated that the <subdomain, bsl, set> is not to be directly encoded/decoded into/from the BIER header itself. It should be derived from the BIFT-id, which is actually the BIER label itself. I'll skip the reasons/advantages here.
Zzh3> 2. BIER non-MPLS was then designed, inheriting the BIER MPLS design. The BIFT-id is not called MPLS label, but the essence is the same (except that the BIER label serves two purposes: "next header" code point + BIFT-id).

Zzh3> The presence/future is as following:
Zzh3> Now BIERin6 just adds a new "next header" code point to IP just so that when an IP tunnel is needed for BIER, BIER non-MPLS can be used as is.
Zzh3> BIERv6 is not just new IPv6 DOH type. It requires changes in all three layers - BIER, IPv6, and overlay forwarding. That's why it needs further discussion.
Zzh3> Jeffrey

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Saturday, November 28, 2020 12:02 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Xuesong,

Jeffrey

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 10:57 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Jeffery,

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Saturday, November 28, 2020 11:32 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Xuesong,

Please see zzh> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Friday, November 27, 2020 9:06 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:[email-masked]]
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thanks,
Shep

---

From: Loa Andersson <[email-masked]>
Date: Mon, 30 Nov 2020 16:29:22 +0800

Folks,

I tried to says this at the meeting. Sometimes back in the Stoneages, we 
startedto specify requiremens.

My manager at that time stressed over and over again, that requirements 
need to be:

- measurable
- verifiable
- testable

Looking at the L2 requirement from draft-ietf-bier-ipv6-requirements-09:

The solution should support various kinds of L2 data link types.

I'd say that should is bad requrement language, it should be "shall". 
Should normalle signifies a goal.

Various is also bad. The implementer needs to know how many. With 
various in the requirement it is possible that two implementations that 
support every other requirement, actually do not support any joint L2 
data link types and thus is incompatible.

Various is also bad because the implementer needs to know which L2 data 
link types.

What about:

The solution shall support the following two L2 data link types, 
Ethernet and HDLC.

/L2

On 29/11/2020 14:43, Gyan Mishra wrote:
> 
> Mike / All
> 
> As Jeffrey mentioned over the course of this detailed thread I flushed 
> out the understanding of BIERin6 and confirmed they no gaps exist.
> 
> As it stands today no changes related to the last contested item related 
> to “RFC 8296 L2 Ethernet” between myself and Jeffrey would change as the 
> BIERin6 draft as Jeffery has stated is an complete holistic solution for 
> an IPV6 environment.  This is a new development as I worked out in my 
> mind per below why L2 should be part of BIERin6 draft.
> 
> BIER header following IPv6 encapsulation header and ICMP code point.  
> The optional BIERin6 would be used in cases where the operator requires 
> IPv6 tunneling or FRR.
> 
> As Jeffrey mentioned there is some text verbiage to be updated 
> pertaining to how the requirements are being met with BIERin6 solution.
> 
> BIERin6 on ML I am in agreement that no gaps exist and that we just have 
> to ensure all verbiage is updated related to meeting any new or existing 
> satisfy all existing and any new requirements added to the draft, 
> however BIERin6 advancement is not dependent on the requirements draft.
> 
> primary solution for IPv6 environments.  The existing layering utilized 
> in Non MPLS BIER Ethernet is utilized in BIERin6 solution moving the 
> BIER header to inner header inside outer IPv6 header with identical 
> layering solution.
> 
> makes the both solutions both homogeneous as well as holistic solution 
> by providing layering parity between the two solutions.  Another 
> important reason why the existing L2 solution should be part of the 
> BIERin6 draft.
> 
> If we are able to clearly identify those BIERin6 gaps that BIERv6 meets 
> and fills those gaps, as well as  all the requirements are met then we 
> can seek WG adoption of BIERv6 draft  as well.
> 
> Kind Regards
> 
> Gyan
> 
> On Sat, Nov 28, 2020 at 4:53 PM Jeffrey (Zhaohui) Zhang 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     To clarify, there is no gap in the BIERin6 solution (besides the new
>     "next header" code point). It's just that some text are needed to
>     explain how the requirements are met with the BIERin6 solution -
>     whether it is a requirement already listed in the current
>     requirements draft, or have been brought up in recent mailing list
>     discussions (I know of two in recent discussions).
> 
>     BIERin6 is based on RFC 8296 (plus the new "next header" code point
>     for IPv6 encapsulation), and is a generic solution with the
>     following properties:
> 
>     4. tunnel type independent - as long as the tunnel header can
>     indicate with a code point that a BIER header follows
>     With the above, there is simply no need for another solution in my
>     view. Of course the WG can continue discussing BIERv6 and may
>     determine that it is nice to have BIERv6 as well, but we should not
>     bundle them together when it comes to adoption. That's why I
>     suggested in the last BIER session the following:
> 
>     - Adopt BIERin6
>     - Discuss BIERv6 further
> 
>     Jeffrey
> 
>     From: Michael McBride <[email-masked]
>     <mailto:[email-masked]>>
>     To: [email-masked] <mailto:[email-masked]>; Jeffrey (Zhaohui)
>     Zhang <[email-masked] <mailto:[email-masked]>>
>     Cc: Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>>; Alvaro Retana
>     <[email-masked] <mailto:[email-masked]>>; BIER WG
>     <[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>; Tony Przygienda
>     <[email-masked] <mailto:[email-masked]>>;
>     draft-ietf-bier-ipv6-requirements
>     <[email-masked]
>     <mailto:[email-masked]>>
>     conversation to advance the discussion. It's clear now that all of
>     the requirements >discussed so far can be addressed by the BIERin6
>     draft if we flesh out the discussed gaps.
> 
>      >BIERin6 to include the gaps discussed here so that it fully
>     encompases the requirements so far described, for WG adoption.
> 
>     I'm sure I'm misinterpreting. What it sounds like you are saying is
>     "I want bierin6 to be adopted so let's fix the gaps so we can
>     begin". Since both solutions meet the requirements, I'm hoping you
>     meant "Let's fix the gaps in bierin6 so we can begin adoption calls
>     for both bierv6 and bierin6".
> 
>     mike
> 
> 
>     On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>      > Hi Gyan,
>      >
>      >
>      >
>      > *From:* Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>>
>      > *To:* Jeffrey (Zhaohui) Zhang <[email-masked]
>     <mailto:[email-masked]>>
>      > *Cc:* Alvaro Retana <[email-masked]
>     <mailto:[email-masked]>>; BIER WG <[email-masked]
>     <mailto:[email-masked]>>;
>      > [email-masked] <mailto:[email-masked]>
>     <[email-masked] <mailto:[email-masked]>>; Tony
>     Przygienda <
>      > [email-masked] <mailto:[email-masked]>>;
>      > [email-masked]
>     <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>> wrote:
>      >
>      > Gyan,
>      >
>      >
>      >
>      > Please see zzh6> below.
>      >
>      >
>      >
>      > *From:* Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>>
>      > *To:* Jeffrey (Zhaohui) Zhang <[email-masked]
>     <mailto:[email-masked]>>
>      > *Cc:* Alvaro Retana <[email-masked]
>     <mailto:[email-masked]>>; BIER WG <[email-masked]
>     <mailto:[email-masked]>>;
>      > [email-masked] <mailto:[email-masked]>
>     <[email-masked] <mailto:[email-masked]>>; Tony
>     Przygienda <
>      > [email-masked] <mailto:[email-masked]>>;
>      > [email-masked]
>     <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>> wrote:
>      >
>      > Hi Gyan,
>      >
>      >
>      >
>      > *From:* Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>>
>      > *To:* Jeffrey (Zhaohui) Zhang <[email-masked]
>     <mailto:[email-masked]>>
>      > *Cc:* Alvaro Retana <[email-masked]
>     <mailto:[email-masked]>>; BIER WG <[email-masked]
>     <mailto:[email-masked]>>;
>      > [email-masked] <mailto:[email-masked]>
>     <[email-masked] <mailto:[email-masked]>>; Tony
>     Przygienda <
>      > [email-masked] <mailto:[email-masked]>>;
>      > [email-masked]
>     <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.com/v3/__https://nam11.safelinks.protection.outloo>
>      >
>     <http://k.com/?url=https*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp>
>      > defense.com
>     <http://defense.com>%2Fv3%2F__https%3A%2Ftools.ietf.org
>     <http://2Ftools.ietf.org>%2Fhtml%2Frfc5332__%3B!!
>      >
>      > 4ssHlj%24&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com
>     <http://40futurewei.com>%7C97b8a34
>      >
>      > Would those be two separate IANA code point requests I what I see
>     from
>      > the packet format.
>      >
>      >
>      >
>      > IANA L2 scenario:
>      >
>     <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&amp;data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$
>     <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&amp;data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$>
>      >.
>      > IANA Considerations
>      >
>      >
>      >
>      >
>      >
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
> 
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 30 Nov 2020 11:22:00 -0000

Hey Jeffrey,

It may be because I'm late to the discussion, but when you say...

> With the above, there is simply no need for another solution in my view.

...this seems to suggest that there is already a solution.
AFAICS, while you might support only one of the two solutions, there are two solutions. Neither has been adopted and neither has been "selected".

You might have better phrased this as "this is simply no need for two solutions." It might be true that most people agree with that, but since they will only agree if their preferred solution is chosen, it is possibly not very helpful.

However, you go on...

> Of course the WG can continue discussing BIERv6 and may determine that it is
> nice to have BIERv6 as well, but we should not bundle them together when it
> comes to adoption.

...which seems to suggest that you don't think it is harmful to discuss two solutions.
Since the adoption of one on its own is likely to reduce the chances of adoption of the other, not bundling the adoptions might be a little simplistic. I am not proposing that we poll the adoption of either solution first. Nor am I suggesting making it an either/or adoption poll.

So how about this?

- BIER has a history of starting with Experimental work and seeing how it develops
- This deployment case is somewhat niche: multicast is a bit rare, BIER is not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous, bridging over IPv6 is a subset of BIER.
- Why not adopt both approaches as Experimental and set some clear terms for the experiment?

Cheers,
Adrian

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 28 November 2020 21:54
To: Michael McBride <[email-masked]>; [email-masked]
Cc: BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>; [email-masked] <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <[email-masked]>
Sent: Saturday, November 28, 2020 2:15 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

mike

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 30 Nov 2020 13:32:30 +0000

Hi Adrian,

Please see zzh> below.

-----Original Message-----
From: Adrian Farrel <[email-masked]>
Sent: Monday, November 30, 2020 6:22 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: 'BIER WG' <[email-masked]>
Subject: RE: [Bier] draft-ietf-bier-ipv6-requirements-09

Hey Jeffrey,

Zzh> RFC 8296 is an existing standard track solution. BIERin6 is RFC8296 plus a new IP "Next Header" code point. I have used "existing solution" to refer to BIERin6, but let me rephrase:

Zzh> With BIERin6 based RFC 9296 with just a new "Next Header" code point, it's ready for the WG to adopt it.
Zzh> My view is that we don't need another one but BIERv6 is worth more discussion. That's why I suggested the following in the last BIER session and in this email:
Zzh> 1. Adopt BIERin6
Zzh> 2. Discuss BIERv6 further

However, you go on...

> Of course the WG can continue discussing BIERv6 and may determine that
> it is nice to have BIERv6 as well, but we should not bundle them
> together when it comes to adoption.

Zzh> I don't think BIERin6 needs more discussion. I had suggested to discuss BIERv6 further.

So how about this?

Zzh> With BIERin6 based on standard track RFC 8296 with just a new "Next Header" code point, it is not reasonable to treat it as experimental.
Zzh> As I had explained, BIERv6 is not as simple as adding a DOH option type code point, so the two are not at the same starting line and should not be forced to the same starting point (adoption call and standard/experimental status).
Zzh>
Zzh> Thanks.
Zzh> Jeffrey

Cheers,
Adrian

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 28 November 2020 21:54
To: Michael McBride <[email-masked]>; [email-masked]
Cc: BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>; [email-masked] <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <[email-masked]>
Sent: Saturday, November 28, 2020 2:15 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

mike

Juniper Business Use Only
_______________________________________________
BIER mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!Ro1rWHyzIJdeZsKduMzs40QMitivSu1AQ9RX8VNAvOVtNgU252AokX-_A_p1YCOB$

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 30 Nov 2020 09:47:34 -0500

Hi Loa

This comment was made recently about L2 links verbiage to specify the exact
link types.  We have comments related to OAM as well as other updates to
add.

We will get the draft  updated.

Thanks

Gyan

On Mon, Nov 30, 2020 at 3:29 AM Loa Andersson <[email-masked]> wrote:

> >      > We have reached consensus as well as are in sync,  and I now have
> a
> >      > better understanding of BIERin6.
> >      >
> >      >
> >      >
> >      > Over the course of this thread we did touch on some technical
> reasons
> >      > why
> >      > I am answering in-line but now connecting the dots how is in
> today’s
> >      > RFC
> >      >    packet (BFIR) with an ICMP code value of TBD10 ('invalid
> options
> >      > for
> >      >
> >      >    BIERin6').
> >      >
> >      >
> >      >
> https://urldefense.com/v3/__https://nam11.safelinks.protection.outloo
> >     <
> https://urldefense.com/v3/__https://nam11.safelinks.protection.outloo>
> >      >
> >
> http://k.com/?url=https*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp
> >
-- 

*Gyan Mishra*

---

From: Michael McBride <[email-masked]>
Date: Mon, 30 Nov 2020 19:05:07 +0000

This!

mike

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of Adrian Farrel
Sent: Monday, November 30, 2020 3:22 AM
To: 'Jeffrey (Zhaohui) Zhang' <zzhang=[email-masked]>
Cc: 'BIER WG' <[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Hey Jeffrey,

However, you go on...

So how about this?

Cheers,
Adrian

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: 28 November 2020 21:54
To: Michael McBride <[email-masked]>; [email-masked]
Cc: BIER WG <[email-masked]>; Gyan Mishra <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>; [email-masked] <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

- Adopt BIERin6
- Discuss BIERv6 further

Jeffrey

-----Original Message-----
From: Michael McBride <[email-masked]>
Sent: Saturday, November 28, 2020 2:15 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Alvaro Retana <[email-masked]>; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Tony Przygienda <[email-masked]>; draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Hi Greg,

mike

On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> defense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outloo&a
> mp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f4bd4d3f2c
> c208d89522310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6374233214
> 00994370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZTD3UoFNPPbw5cq63CD77bJ
> 6NP3gwiaciyErJ1OMMFI%3D&amp;reserved=0
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24%26amp%3Bdata%3D04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26amp%3Bsdata%3DnEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N%24&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f4bd4d3f2cc208d89522310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637423321400994370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=fszY8MUPUn7HymiDWii297tMT7ztwl1VwUcn25Rlo58%3D&amp;reserved=0 >.
> IANA Considerations
>
>
>
>
>

Juniper Business Use Only
_______________________________________________
BIER mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f4bd4d3f2cc208d89522310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637423321401004365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=z%2FZLlPIEI9raumWwe9iKpI7wLJcoedPNZUKPepNLuR0%3D&amp;reserved=0

_______________________________________________
BIER mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Cb501cd53f4bd4d3f2cc208d89522310a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637423321401004365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=z%2FZLlPIEI9raumWwe9iKpI7wLJcoedPNZUKPepNLuR0%3D&amp;reserved=0