Subject: Re: [Bier] In reply to the formal complaints

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 3 Jun 2021 04:50:27 +0000

Dear Martin,

Thanks for your response to my complaints. Although it has been 12 weeks since my original email, I understand that there are other things on your time as AD and that this was a detailed issue for you to research.

We look forward to more open and effective communications with the WG chairs, and we are hopeful for the fair and open discussion that you expect. 
It will be good to see the chairs' summary of the discussions regarding the BIERv6 solution in general and regarding the specific document which proposes a solution. This may help explain their attitude towards the work.  From my point of view, it will be more suitable to invite 3rd party to have the summary instead of having the summary by the chairs self.

Of course, you are right that the individual issues that caused us to make a complaint could each have happened for understandable and reasonable reasons. On its own many issues are not critical. But it still feels to me that there was a pattern or behavior that always makes our work come out at the bottom. Please know that we do not object to the WG adopting BIERin6, but we are not happy that BIERin6 and BIERv6 are not given the same opportunity to be presented or discussed in the WG. Actually there was proposal to adopt both drafts and make them experimental until it was clear which had support in the market place. 

Nothing in your email puts in place any process to ensure that the WG will discuss fairly in future. So I would like to understand from the WG chairs and from you some solid suggestions to make this happen and here are some actions I would like to propose based on your suggestions in the response:
- Wait for chairs or 3rd party to produce their summary of discussion of BIER IPv6 topic.
- Opportunity to answer the summary in email list or at IETF-111.
- Full consideration by WG of adopting BIERv6 along with BIERin6.
- No progress on BIERin6 until first three points addressed.

Best Regards,
Jingrong

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Martin Vigoureux
Sent: Monday, May 31, 2021 9:29 PM
To: [email-masked]
Subject: [Bier] In reply to the formal complaints

WG

First, I'd like to apologize for the time this has taken.

I have reviewed the two formal complaints that were sent early March, 
and I have also reviewed most of the e-mails that were sent on the bier 
mailing list for the past 12 months or so, relating to BIER and IPv6.

I will not individually discuss the various points raised, rather I will 
make a general statement.

It is my opinion that a certain number of points are not critical (in 
the sense of not needing an AD to step-in) and some typically happen 
sometimes as part of the life cycle of WGs. Yet, I do recognize that 
some points are more problematic than others.
Further, it is my opinion that the points listed may arise from a 
variety of intentions and as such it is hazardous to associate them with 
a particular one.
It is however my opinion that the multiplicity of concerns is, in 
itself, a concern.
I have talked with the chairs. They do recognize that, at some 
occasions, their communication was not the most effective one, and I 
trust they will pay attention to that in the future.

About the adoption poll on draft-zhang-bier-bierin6. Although the way 
this was handled raised some concerns, I'd like to remind that an 
adoption poll is not formally part of our processes, even if it is 
common practice, and in fact it only marks the start of the WG 
discussion. As such, I have little arguments to go back on this.

The last part is about the progress of a so-called BIER v6 solution. 
Here, I have asked the chairs to establish a summary of the discussions 
regarding that type of solution in general and regarding the specific 
document which proposes a solution. They should publish it some time 
after this e-mail.

Following that, it is my expectation that the WG has a fair and open 
discussion, ideally focussing on the general aspects, and then concludes 
on the way forward.

Martin

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

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 3 Jun 2021 04:19:52 -0700

Thanks you Martin for your time and effort. I will send our summary on a
dedicated thread for discussion

Cheers,
Greg

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 11 Jun 2021 11:40:03 +0000

Dear Martin,

We've responded to the summary from chairs on that thread. I think it reflects the key technical differences between us and the chairs. 
>From chairs' point of view, BIERv6 violates BIER architecture, which is L2 in nature and should not be IPv6/SRv6 dependent.
>From our point of view, BIERv6 does not violate BIER architecture, which should be interpreted by RFC8279 text instead of other informal interpretation.

For the detailed technical points in the BIERv6 solution, we think they have been checked carefully in BIER WG and other WGs for long time, and have been proven by implementation and test.
Also there are solid requirements from industry to have well-adapted BIER solution in IPv6/SRv6 network. 

We seek for your guidance to move our work forward in IETF. We would like to propose two options about what should be done in the next step: 
1) Consider to adopt BIERv6 in BIER WG, if BIERv6 complies with BIER architecture.
2) Move BIERv6 work to other WG, e.g., PIM or SPRING, if BIERv6 does not comply with BIER architecture. 

Thank you very much for your help.

Jingrong

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Martin Vigoureux
Sent: Monday, May 31, 2021 9:29 PM
To: [email-masked]
Subject: [Bier] In reply to the formal complaints

WG

I have reviewed the two formal complaints that were sent early March, and I have also reviewed most of the e-mails that were sent on the bier mailing list for the past 12 months or so, relating to BIER and IPv6.

I will not individually discuss the various points raised, rather I will make a general statement.

It is my opinion that a certain number of points are not critical (in the sense of not needing an AD to step-in) and some typically happen sometimes as part of the life cycle of WGs. Yet, I do recognize that some points are more problematic than others.
Further, it is my opinion that the points listed may arise from a variety of intentions and as such it is hazardous to associate them with a particular one.
It is however my opinion that the multiplicity of concerns is, in itself, a concern.
I have talked with the chairs. They do recognize that, at some occasions, their communication was not the most effective one, and I trust they will pay attention to that in the future.

About the adoption poll on draft-zhang-bier-bierin6. Although the way this was handled raised some concerns, I'd like to remind that an adoption poll is not formally part of our processes, even if it is common practice, and in fact it only marks the start of the WG discussion. As such, I have little arguments to go back on this.

The last part is about the progress of a so-called BIER v6 solution. 
Here, I have asked the chairs to establish a summary of the discussions regarding that type of solution in general and regarding the specific document which proposes a solution. They should publish it some time after this e-mail.

Following that, it is my expectation that the WG has a fair and open discussion, ideally focussing on the general aspects, and then concludes on the way forward.

Martin

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 14 Jun 2021 14:01:27 +0200

Dear Jingrong,

please see in-line

>>From our point of view, BIERv6 does not violate BIER architecture, which should be interpreted by RFC8279 text instead of other informal interpretation.

it appears to me that this is the discussion the WG needs to have and 
reach consensus on.

-m

---

From: Michael McBride <[email-masked]>
Date: Thu, 17 Jun 2021 00:46:53 +0000

Howdy,

>it appears to me that this is the discussion the WG needs to have and reach consensus on.

My take from the chairs summary is that they believe BIERv6 is simply unnecessary, not that it violates the bier architecture. 

There are many of us who believe using EH for the bitstring is a great use of IPv6 with bier. This was presented in 6man with positive feedback. Perhaps the time has come to propose this work in an IPv6 EH friendly WG? 

mike

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmmcbride%40fut
> urewei.com%7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C637592689222267034%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
> p;sdata=ng78EEFJ0jNyOSdkvfv4Ic6xB3%2FpZkfY66Q%2BWdGZfIk%3D&amp;reserve
> d=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%7Cmmcbride%40futurewei.com%7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637592689222277027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dcV1PufJOI0NEKjONjsDIKK3Ib7%2BBF7xiHasDrnGTQs%3D&amp;reserved=0

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 16 Jun 2021 23:54:20 -0400

Some thoughts on future progression possibilities for BIERv6.

As the BIER architecture is based on simple simple encapsulation and
layering L2 1/2 MPLS BIER or Non MPLS BIER Ethernet - BIERin6.

BIERv6 with utilizes the  IPv6 data plane falls out of scope of the BIER
charter even though maybe a viable solution due to the fact that it
utilizes the IPv6 data plane for encoding the BIER header is where the
solution ran into trouble gaining consensus within the WG.

So it’s not that the solution is not a solid or viable solution, but the
fact that it relies on the IPv6 data plane for encoding BIER layer which
ends up being unfortunately out of scope with BIER WG.

A good example of a similar issue related to a technology that uses the
IPv6 data plane falling out of scope of the intended WG where the
architecture resides is SRv6.

SRv6 PGM RFC8986 and SRv6 SRH RFC 8754 are part of the Spring WG Segment
routing architectures, however all the development fell out of the WG as
Spring is chartered for Source Routing framework, however since SRv6
utilizes the IPv6 data plane it fell outside of the scope of the Spring WG.

So both SRv6 PGM RFC8986 and SRv6 SRH RFC 8754 were developed, adopted and
progressed to RFC in 6MAN which owns the IPv6 data plane and any technology
that utilizes  the IPv6 data plane.

During the development, WG adoption and WGLC both WGs Spring and 6MAN
collaborated on the development of the specification.  There were some
definite snags with RFC 8200 and following the IPv6 specification to a
letter but in the end we all came to agreement and both drafts finally
progressed to RFC.

I think BIERin6 as it utilizes the IPv6 data plane could be progressed in
6MAN are my thoughts and developed.  Both WGs would collaborate together to
progress the draft.

My 2 cents

Kind Regards

Gyan

On Wed, Jun 16, 2021 at 8:47 PM Michael McBride <[email-masked]>
wrote:

> > We've responded to the summary from chairs on that thread. I think it
> reflects the key technical differences between us and the chairs.
> >>From chairs' point of view, BIERv6 violates BIER architecture, which is
> L2 in nature and should not be IPv6/SRv6 dependent.
> >>From our point of view, BIERv6 does not violate BIER architecture, which
> should be interpreted by RFC8279 text instead of other informal
> interpretation.
>
> My take from the chairs summary is that they believe BIERv6 is simply
> unnecessary, not that it violates the bier architecture.
>
> There are many of us who believe using EH for the bitstring is a great use
> of IPv6 with bier. This was presented in 6man with positive feedback.
> Perhaps the time has come to propose this work in an IPv6 EH friendly WG?
>
> mike
>
> >
> > For the detailed technical points in the BIERv6 solution, we think they
> have been checked carefully in BIER WG and other WGs for long time, and
> have been proven by implementation and test.
> > We seek for your guidance to move our work forward in IETF. We would
> like to propose two options about what should be done in the next step:
> sometimes as part of the life cycle of WGs. Yet, I do recognize that some
> points are more problematic than others.
> variety of intentions and as such it is hazardous to associate them with a
> particular one.
> occasions, their communication was not the most effective one, and I trust
> they will pay attention to that in the future.
> >
> this was handled raised some concerns, I'd like to remind that an adoption
> poll is not formally part of our processes, even if it is common practice,
> and in fact it only marks the start of the WG discussion. As such, I have
> little arguments to go back on this.
> >
> document which proposes a solution. They should publish it some time after
> this e-mail.
> >
> discussion, ideally focussing on the general aspects, and then concludes on
> the way forward.
> >
> >
> > Martin
> >
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 16 Jun 2021 22:08:04 -0700

Inline:

> unnecessary, not that it violates the bier architecture.

GS - Correct

> of IPv6 with bier.

GS - "Great use" is not a valid use-case. The WG has been asking the
authors for years what the compelling use case is to motivate creating
layer dependencies and we are still waiting.

> This was presented in 6man with positive feedback.

GS - No, it was presented in 6man and the authors were told 6man had no
issues with it from a v6 perspective but that the work needed to work
through the BIER WG for all BIER issues. And the WG is rather exhausted at
having to repeatedly address the same miss-represetned issues, miss-quoted
members of other lists, and having our questions ignored. You are
essentially DOS-ing the WG process rather than listening and collaborating.
It's clear you are unwilling to work collaboratively within the group.
We've tried.

> Perhaps the time has come to propose this work in an IPv6 EH friendly WG?

GS - I trust you understand how the standards process works. Good luck.

Greg

---

From: Michael McBride <[email-masked]>
Date: Thu, 17 Jun 2021 05:46:35 +0000

And around and around we go. It's at least good to see that the consistent tone in this wg hasn't changed. Congrats, you win.

mike

From: Greg Shepherd <[email-masked]>
Sent: Wednesday, June 16, 2021 10:08 PM
To: Michael McBride <[email-masked]>
Cc: Martin Vigoureux <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; [email-masked]
Subject: Re: [Bier] In reply to the formal complaints

Inline:

On Wed, Jun 16, 2021 at 5:47 PM Michael McBride <[email-masked]<mailto:[email-masked]>> wrote:
Howdy,

GS - Correct

There are many of us who believe using EH for the bitstring is a great use of IPv6 with bier.

GS - "Great use" is not a valid use-case. The WG has been asking the authors for years what the compelling use case is to motivate creating layer dependencies and we are still waiting.

GS - No, it was presented in 6man and the authors were told 6man had no issues with it from a v6 perspective but that the work needed to work through the BIER WG for all BIER issues. And the WG is rather exhausted at having to repeatedly address the same miss-represetned issues, miss-quoted members of other lists, and having our questions ignored. You are essentially DOS-ing the WG process rather than listening and collaborating. It's clear you are unwilling to work collaboratively within the group. We've tried.

Greg

mike

> From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Martin
> Vigoureux
> To: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Cmmcbride%40futurewei.com%7C39f5a21bd67547def16c08d9314dead7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637595032998824225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9qNrnHHa7VdwsCY%2FOlS8relKjlKU6x3%2F0q98sGdH2CU%3D&reserved=0>%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmmcbride%40fut
> urewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Furewei.com%2F&data=04%7C01%7Cmmcbride%40futurewei.com%7C39f5a21bd67547def16c08d9314dead7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637595032998824225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yFSxNQ%2FDaMEyh%2FYcllCsBjnFI3Cb1PZqggpBLRlWtxk%3D&reserved=0>%7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637592689222277027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dcV1PufJOI0NEKjONjsDIKK3Ib7%2BBF7xiHasDrnGTQs%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Cmmcbride%40futurewei.com%7C39f5a21bd67547def16c08d9314dead7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637595032998834209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8ZtLrOfgk1Qm8t8LLBKpq4Vjiz5EGrMUiTSY5M6yTyQ%3D&reserved=0>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Cmmcbride%40futurewei.com%7C39f5a21bd67547def16c08d9314dead7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637595032998844203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uKjUyVSEXDzwFWdHn3CH5qPTEIc5xwZnYWgf30ec1IU%3D&reserved=0>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 17 Jun 2021 10:55:09 +0200

On Thu, Jun 17, 2021 at 7:08 AM Greg Shepherd <[email-masked]> wrote:

>> >>From our point of view, BIERv6 does not violate BIER architecture,
>> which should be interpreted by RFC8279 text instead of other informal
>> interpretation.
>>

IETF has documented processes, we run the WG on those. If authors don't
like the process or see it violated, it is not the job of the WG to
change/adopt/invent IETF processes until they deliver results that
rubberstamps the authors' opinions and desires and the process itself
provides recourse which the authors already took. So we had this shadowy
round-abouting key technical questions while trying to bend the processes
going for quite a long time and burning lots of cycles and patience. Then,
unless we have serious new technical arguments or answer to
use-case/necessity for non-orthogonal, layer shortcutting new encoding all
the other stuff on the thread is in fact just DoS'ing the process more and
more AFAIS.

-- tony

---

From: Lizhenbin <[email-masked]>
Date: Thu, 17 Jun 2021 16:51:14 +0000

Hi Folks,
Through the discussion, we can learn more about the conflict of the design consideration between BIERin6 and BIERv6. In my opinion, it is not appropriate to consider BIERv6 and BIERin6 as the competitive solutions thought there is some overlap. The relationship between BIERv6 and BIERin6 is similar as that between SR-MPLS over IP and SRv6 which can be co-exist for the different scenarios.
- For BIERin6, it tries to keep the BIER as an independent layer and takes the IPv6 as the transport tunnel. (In SR-MPLS over IP, the MPLS is the independent layer from the IP)
- For BIERv6, it takes the native IPv6 design like SRv6.

According to the design, there can be different applications scenarios:
1. For MVPN, with BIERin6, the MPLS label can be allocation for the MVPN instance and can be carried in the BIER layer. BIERv6 will not support the usecase. As the native IPv6 design, it will always use the IPv6 segment to indicate the MVPN instance.
2. With BIERv6, it is easy to support the advanced features such as the fragment and IPSEC functionalities combining with the existing IPv6 extension headers. On the contrary, in order to support these features in the BIERin6 solutions which take the BIER as an independent layer, Jeffery proposed the draft to define the general transport header for the BIER layer to support the fragment and IPSec features. But I do not think it is enough. Now the new functionalities such as network slicing, IOAM and other new functionalities have been proposed. According to the solutions of BIERin6, it is necessary to go on define the extension headers in the BIER layer. If so, for the BIERin6, the fragment/IPSec/network slicing/IOAM headers/options can exist in both the IPv6 extension headers and the BIER layer. We also need the specification to define how to process the co-existence of the same functionalities in IPv6 layer and BIER layer. In my opinion, this is not reasonable and necessary.
I am not sure how ambitious the BIER WG to keep the BIER as the independent layer. If it is ambitious enough, there can be the functionalities including fragment, IPSec, IOAM network slicing, APN, etc. to be developed in the BIER layer. At the same time, the similar functionalities are being developed in the MPLS data plane and the IPv6 data plane. So we will encounter the following challenges:
1) With BIERin6, it will be the following options:
Option 1: IPv6 basic header + BIER layer (including fragment, IPSec, IOAM network slicing, APN, etc.)
Option 2: IPv6 header (including fragment, IPSec, IOAM network slicing, APN, etc. ) + BIER layer (including fragment, IPSec, IOAM network slicing, APN, etc.)
No matter whatever options, the doubt will be arised why duplicate functionalites are developed in both the IPv6 layer and the BIER layer.
2) For BIER in MPLS, it seems the BIER header is only encapsulated in the MPLS encapsulation as other functionalities instead of maintaining an independent layer. I am not sure about the conclustion. If it is yes, it seems conflicted with the design concept claimed by BIERin6 to keep BIER as the independent layer. If it is not, BIER will be kept as the independent layer and there will be the following case:
MPLS layer (including fragment, IPSec, IOAM network slicing, APN, etc.) + BIER layer (including fragment, IPSec, IOAM network slicing, APN, etc.)
The doubt will be arised again why duplicate functionalites are developed in both the MPLS layer and the BIER layer.
When the BIER WG was setup, it cannot be expected later there would be many new funcationalities to be developed. I do not think it is appropriate to be strict with the layered architecture of BIER. And the scope of the BIERin6 solution should also be controlled. Though it seems possible to support the above new functionalities with the layered architecture insisted by the BIERin6, it may cause a mess of the architecture design. But with BIERv6, the advanced functionalities can be supported easily.
This is similar as the relation between SR-MPLS over UDP and SRv6. SR-MPLS over IP is claimed as “a poor man solution” and the scope is maily confine to traverse the IP domain. On the contrary, in the solution of SRv6, the advanced features are supported in the IPv6 layer.
3. Moreover, since the BIERv6 takes the native IPv6 design, there is the possibility that the multicast funcation can be directly initiated in the host side, That is, the BIERv6 can be deployed host-to-host traversing the network domain. This is like the SRv6 to introduce some extention of socket which has been implemented in the Linux. For BIERin6, I do not think there is the possibility.

The above analysis can be summarized as follows:
1. BIERin6 can also support MPLS-based MVPN while BIERv6 will not support the functionality.
2. For the series of functionalities such as the fragment, IPSec, network slicing, IOAM, APN, etc. which is being developed in the MPLS layer and IPv6 layer, even if there is the possibility to support these functionalities in the BIER layer which is insisted by the BIERin6, it may caust the mess in the architecute design involving the MPLS/IPv6/BIER layer. I suggest the advanced functionalities should be implemented directly in the IPv6 layer like BIERv6 or the MPLS layer.
3. For the future possible host-to-host deployment, BIERv6 should take it rather than BIERin6.

Like the co-existence of SR-MPLS over UDP and SRv6, there should be the co-eixstence BIERin6 and BIERv6 for the different scenarios even if there is the overlap. And there should not be the mess in the BIER WG. If it is insisted that the layered architecture and the encoding of the BIER header should not be changed (for BIERv6, some fields of the BIER header are truly unnecessary) in the BIER WG, since the BIERv6 adopts the same design concept as the SRv6, the work can be done in the SPRING WG (in fact the END.BIER can also be seen as a new flavor of the END in SRv6). Or like the TREE SID, the work can be done in the PIM WG where the multicast source routing can be explored together.

Best Regards,
Robin

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Thursday, June 17, 2021 1:08 PM
To: m00759202 <[email-masked]>
Cc: Xiejingrong (Jingrong) <[email-masked]>; [email-masked]; Martin Vigoureux <[email-masked]>
Subject: Re: [Bier] In reply to the formal complaints

Inline:

GS - Correct

Greg

mike

> ietf.org<http://ietf.org>%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmmcbride%40fut
> urewei.com<http://urewei.com>%7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Jun 2021 20:36:33 +0100

Greg,

Is it necessary to take a hostile and aggressive approach to these discussions? I am sure you are frustrated and want to move forward, but it feels like you are shutting down discussions rather than trying to resolve them.

Telling someone that they are “unwilling to work collaboratively within the group” is probably not conducive to encouraging them to work collaboratively.

My understanding was that the AD has engaged with you to work on the clarity of your communication, and your email is certainly very clear. But I don’t think it is very nice. We look to those in leadership positions to set the tone for the work in the IETF, and you need to do better.

Thanks,

Adrian

From: BIER <[email-masked]> On Behalf Of Greg Shepherd
Sent: 17 June 2021 06:08
To: Michael McBride <[email-masked]>
Cc: Xiejingrong (Jingrong) <[email-masked]>; [email-masked]; Martin Vigoureux <[email-masked]>
Subject: Re: [Bier] In reply to the formal complaints

Inline:

On Wed, Jun 16, 2021 at 5:47 PM Michael McBride <[email-masked] <mailto:[email-masked]> > wrote:

Howdy,

GS - Correct

Greg

mike

> From: BIER [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Martin 
> Vigoureux
> To: [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]> 
> ietf.org <http://ietf.org> %2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmmcbride%40fut
> urewei.com <http://urewei.com> %7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a

_______________________________________________
BIER mailing list
[email-masked] <mailto:[email-masked]> 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637592689222277027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dcV1PufJOI0NEKjONjsDIKK3Ib7%2BBF7xiHasDrnGTQs%3D&amp;reserved=0> &amp;data=04%7C01%7Cmmcbride%40futurewei.com%7C251aa4cc378a4f70fee008d92f2c3757%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637592689222277027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dcV1PufJOI0NEKjONjsDIKK3Ib7%2BBF7xiHasDrnGTQs%3D&amp;reserved=0

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

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 17 Jun 2021 22:03:11 -0400

Dear WG

As co-author of both drafts, Robin makes very good points in the comparison
and contrast of BIERIn6 and BIERv6 to Segment Routing SR-MPLS layering
reusing of the MPLS data plane comparison to BIERIn6 and SRv6 using the
native IPv6 data plane comparison to BIERv6.

Kind Regards

Gyan

On Thu, Jun 17, 2021 at 12:51 PM Lizhenbin <[email-masked]> wrote:

> Hi Folks,
>
> Through the discussion, we can learn more about the conflict of the design
> consideration between BIERin6 and BIERv6. In my opinion, it is not
> appropriate to consider BIERv6 and BIERin6 as the competitive solutions
> thought there is some overlap. The relationship between BIERv6 and BIERin6
> is similar as that between SR-MPLS over IP and SRv6 which can be co-exist
> for the different scenarios.
>
> - For BIERin6, it tries to keep the BIER as an independent layer and takes
> the IPv6 as the transport tunnel. (In SR-MPLS over IP, the MPLS is the
> independent layer from the IP)
>
> 1. For MVPN, with BIERin6, the MPLS label can be allocation for the MVPN
> instance and can be carried in the BIER layer. BIERv6 will not support the
> usecase. As the native IPv6 design, it will always use the IPv6 segment to
> indicate the MVPN instance.
>
> 2. With BIERv6, it is easy to support the advanced features such as the
> fragment and IPSEC functionalities combining with the existing IPv6
> extension headers. On the contrary, in order to support these features in
> the BIERin6 solutions which take the BIER as an independent layer, Jeffery
> proposed the draft to define the general transport header for the BIER
> layer to support the fragment and IPSec features. But I do not think it is
> enough. Now the new functionalities such as network slicing, IOAM and other
> new functionalities have been proposed. According to the solutions of
> BIERin6, it is necessary to go on define the extension headers in the BIER
> layer. If so, for the BIERin6, the fragment/IPSec/network slicing/IOAM
> headers/options can exist in both the IPv6 extension headers and the BIER
> layer. We also need the specification to define how to process the
> co-existence of the same functionalities in IPv6 layer and BIER layer. In
> my opinion, this is not reasonable and necessary.
>
> I am not sure how ambitious the BIER WG to keep the BIER as the
> independent layer. If it is ambitious enough, there can be the
> functionalities including fragment, IPSec, IOAM network slicing, APN, etc.
> to be developed in the BIER layer. At the same time, the similar
> functionalities are being developed in the MPLS data plane and the IPv6
> data plane. So we will encounter the following challenges:
>
> Option 2: IPv6 header (including fragment, IPSec, IOAM network slicing,
> APN, etc. ) + BIER layer (including fragment, IPSec, IOAM network slicing,
> APN, etc.)
>
> No matter whatever options, the doubt will be arised why duplicate
> functionalites are developed in both the IPv6 layer and the BIER layer.
>
> 2) For BIER in MPLS, it seems the BIER header is only encapsulated in the
> MPLS encapsulation as other functionalities instead of maintaining an
> independent layer. I am not sure about the conclustion. If it is yes, it
> seems conflicted with the design concept claimed by BIERin6 to keep BIER as
> the independent layer. If it is not, BIER will be kept as the independent
> layer and there will be the following case:
>
> MPLS layer (including fragment, IPSec, IOAM network slicing, APN, etc.) +
> BIER layer (including fragment, IPSec, IOAM network slicing, APN, etc.)
>
> The doubt will be arised again why duplicate functionalites are developed
> in both the MPLS layer and the BIER layer.
>
> When the BIER WG was setup, it cannot be expected later there would be
> many new funcationalities to be developed. I do not think it is appropriate
> to be strict with the layered architecture of BIER. And the scope of the
> BIERin6 solution should also be controlled. Though it seems possible to
> support the above new functionalities with the layered architecture
> insisted by the BIERin6, it may cause a mess of the architecture design.
> But with BIERv6, the advanced functionalities can be supported easily.
>
> This is similar as the relation between SR-MPLS over UDP and SRv6. SR-MPLS
> over IP is claimed as “a poor man solution” and the scope is maily confine
> to traverse the IP domain. On the contrary, in the solution of SRv6, the
> advanced features are supported in the IPv6 layer.
>
> 3. Moreover, since the BIERv6 takes the native IPv6 design, there is the
> possibility that the multicast funcation can be directly initiated in the
> host side, That is, the BIERv6 can be deployed host-to-host traversing the
> network domain. This is like the SRv6 to introduce some extention of socket
> which has been implemented in the Linux. For BIERin6, I do not think there
> is the possibility.
>
>
>
> 2. For the series of functionalities such as the fragment, IPSec, network
> slicing, IOAM, APN, etc. which is being developed in the MPLS layer and
> IPv6 layer, even if there is the possibility to support these
> functionalities in the BIER layer which is insisted by the BIERin6, it may
> caust the mess in the architecute design involving the MPLS/IPv6/BIER
> layer. I suggest the advanced functionalities should be implemented
> directly in the IPv6 layer like BIERv6 or the MPLS layer.
>
> Like the co-existence of SR-MPLS over UDP and SRv6, there should be the
> co-eixstence BIERin6 and BIERv6 for the different scenarios even if there
> is the overlap. And there should not be the mess in the BIER WG. If it is
> insisted that the layered architecture and the encoding of the BIER header
> should not be changed (for BIERv6, some fields of the BIER header are truly
> unnecessary) in the BIER WG, since the BIERv6 adopts the same design
> concept as the SRv6, the work can be done in the SPRING WG (in fact the
> END.BIER can also be seen as a new flavor of the END in SRv6). Or like the
> TREE SID, the work can be done in the PIM WG where the multicast source
> routing can be explored together.
>
>
>
>
>
> Best Regards,
>
> Robin
>
>
>
>
>
>
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Greg Shepherd
> *Sent:* Thursday, June 17, 2021 1:08 PM
> *To:* m00759202 <[email-masked]>
> *Cc:* Xiejingrong (Jingrong) <[email-masked]>; [email-masked];
> Martin Vigoureux <[email-masked]>
> *Subject:* Re: [Bier] In reply to the formal complaints
>
>
>
> Inline:
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Fri, 18 Jun 2021 11:10:27 +0800 (CST)

Hi Robin, 
The viewpoints you raised here have been discussed round and round. 
If you have difficulty to find the discussion in the mailing list before, please see this summary for BIERin6 from Jeffrey in the adoption discussion round (https://mailarchive.ietf.org/arch/msg/bier/0h09rZ8sgBlrzx9awtZc44y4XHg/):
1. BIERin6 is to apply the existing generic solution to IPv6 networks, with a clean layered architecture. All that is needed are code points for outer header to indicate the payload is BIER. In case of IPv6 tunneling (single hop or multi-hop), that's a code point for IP "next header".
2. It does satisfy all requirements listed in the requirements draft, including supporting SRv6 based services.
3. With the above considerations, it is ready for WG adoption on standards track, and should not be tied with other solutions (which may progress on their own paces).
Thanks,
Sandy

------------------原始邮件------------------
发件人：Lizhenbin
收件人：[email-masked];m00759202;
抄送人：Xiejingrong (Jingrong);[email-masked];Martin Vigoureux;
日 期 ：2021年06月18日 00:51
主 题 ：Re: [Bier] In reply to the formal complaints
_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

Hi Folks,

2. With BIERv6, it is easy to support the advanced features such as the fragment and IPSEC functionalities combining with the existing IPv6 extension  headers. On the contrary, in order to support these features in the BIERin6 solutions which take the BIER as an independent layer, Jeffery proposed the draft to define the general transport header for the BIER layer to support the fragment and IPSec features.  But I do not think it is enough. Now the new functionalities such as network slicing, IOAM and other new functionalities have been proposed. According to the solutions of BIERin6, it is necessary to go on define the extension headers in the BIER layer. If  so, for the BIERin6, the fragment/IPSec/network slicing/IOAM headers/options can exist in both the IPv6 extension headers and the BIER layer. We also need the specification to define how to process the co-existence of the same functionalities in IPv6 layer  and BIER layer. In my opinion, this is not reasonable and neces
 sary.

Best Regards,
Robin

Inline:

On Wed, Jun 16, 2021 at 5:47 PM Michael McBride <[email-masked]> wrote:
Howdy,

GS - Correct

Greg

mike

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 18 Jun 2021 09:56:53 +0200

Keeping it terse to not make it another 100 mails rehash of endless threads
along the same lines we had over last 1.5 years or so. \

First, I advise the usual suspects here to not start to steer the thread
(which should concern itself with any relevant technical angle & input if
there is some to be had) again towards their technical content free
personal beliefs, opinions, preferences, feelings and borderline personal
attacks and gripes about the process and WG. Enough of that has been had on
lists and WG chats to the point of extending formal complaints already ...

Second, given Robin is a newcomer to discussion here I extend very terse
answer since the arguments can be found in archives and according complaint
communications. So I only answer some summary points

As first observation, I think it is time to point out to the authors & your
company proponents of BIERv6 that there is NO BIERv6. BIER does have a
version field under governance of an IETF registry and what you talking
about in your email is clearly "BIER encoded in SRv6" so we would
appreciate enormously if you'll call this work from now on something along
the lines of "SRv6 BIER encoding" and hence we will avoid confusion by
folks trying to understand the technical content of this work and think
it's some kind of new BIER version or BIER tunneling.

Point 2: it seems that your feeling goes towards "layering is bad, flat is
good, IPv6 L3 encoding can replace everything with enough option hacks and
redefining addresses to mean other things". This is purely a preference
whereas the world's internet has been built on a layered, distributed
networking stack providing an address and layer based security architecture
without controllers. Moreover, attempts to build L3 multicast
replication/tunneling/signalling in one blob were tried and if they would
have been successful BIER WG would not be even chartered. Further I observe
that lots of things you assume as chartered/given/solved are quite
ambitious such as _multicast_ OAM in SRv6 and multicast fragmentation while
ignoring things like RFC8085 (or maybe assumption is that SRv6 will add
multicast MTU discovery as well) and liberally adding things you like to
RFC8279. Following this philosophy, ethernet OAM is probably on its way to
be replaced as well ;-)

Point 3: AFAIS to implement BIERin6 on linux it seems all is needed is a
raw v6 socket with next protocol BIER without any kernel modules or
extensions so I read your assertion that SRv6 encoded BIER is somehow
superior on host purely as personal belief.

Ultimately, I don't seem to see any technical issues summarized during the
format complaint  addressed in detail in your email. As example, I still
don't see any use case "SRv6 encapsed BIER" solves that BIERin6 doesn't
simply solve which is one of the key consideration while I read a lot of
assumptions and preferences about what BIER should be in eyes of SRv6
which, while acknowledged, do not seem to contribute anything substantially
new to the long drawn out discussion or the technical arguments extended
while we closed the process of considering the draft's merits to fit into
WG as work item

thanks

--- tony

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 18 Jun 2021 07:24:19 -0700

Adrian,

It is the conclusion of the WG that creating a layer dependency -
fusion/melding of overlay forwarding layer, BIER forwarding layer, and
lower transport layer - would take the standard in the wrong direction.
Replication has been bound to unicast forwarding planes for more than 30
years. BIER has finally brought a dedicated, independent replicating
forwarding plane to the Internet Architecture. It would be irresponsible to
ignore the original concerns that started BIER on the Experimental Track
now that it has just started to develop on the Standards Track.

The BIER WG will be updating RFC 8279 and has already a list of volunteers
for the task, but you are welcome to join. This work should be published
shortly and I encourage you to contribute your scrutiny to that draft when
available.

Thanks for your help,
Greg

On Thu, Jun 17, 2021 at 12:36 PM Adrian Farrel <[email-masked]> wrote:

> Greg,
>
>
>
> Is it necessary to take a hostile and aggressive approach to these
> discussions? I am sure you are frustrated and want to move forward, but it
> feels like you are shutting down discussions rather than trying to resolve
> them.
>
>
>
> Telling someone that they are “unwilling to work collaboratively within
> the group” is probably not conducive to encouraging them to work
> collaboratively.
>
>
>
> My understanding was that the AD has engaged with you to work on the
> clarity of your communication, and your email is certainly very clear. But
> I don’t think it is very nice. We look to those in leadership positions to
> set the tone for the work in the IETF, and you need to do better.
>
>
>
> Thanks,
>
> Adrian
>
>
>
>
>
> *From:* BIER <[email-masked]> *On Behalf Of *Greg Shepherd
> *Sent:* 17 June 2021 06:08
> *To:* Michael McBride <[email-masked]>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 29 Jun 2021 07:06:25 -0700

Mike,

Sorry for responding so quickly without taking the time to think this
through, again. My position on this draft is no secret, but let me clarify:
Inline GS:

> unnecessary, not that it violates the bier architecture.

GS - My position from the beginning is that it violates the BIER
architecture. I have been clear about this since rev 0. But, I have also
said that IF there was some compelling benefit from the proposal that it
should be considered. But it doesn't offer anything over standard
encapsulation. So, 'yes', it violates the BIER architecture, and 'yes' it
is unnecessary in that it doesn't provide any value over standard
encapsulation.

It is also my position that re-asking the same question in hopes to find
some crack to squeeze through is not operating in good-faith within the WG
or the IETF.

Please let me know if there's anything else I need to restate to make
clear. Again.

Thanks,
Greg