Re: [Bier] In reply to the formal complaints

Lizhenbin <> Thu, 17 June 2021 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDC333A26A5 for <>; Thu, 17 Jun 2021 09:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LnSwZQo_Nx52 for <>; Thu, 17 Jun 2021 09:51:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE50B3A26A3 for <>; Thu, 17 Jun 2021 09:51:19 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4G5SR30cZzz6K6Xr; Fri, 18 Jun 2021 00:38:07 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 17 Jun 2021 18:51:16 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 18 Jun 2021 00:51:14 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Fri, 18 Jun 2021 00:51:14 +0800
From: Lizhenbin <>
To: "" <>, m00759202 <>
CC: "Xiejingrong (Jingrong)" <>, "" <>, Martin Vigoureux <>
Thread-Topic: [Bier] In reply to the formal complaints
Thread-Index: AQHXViEKhd2qqIBYvUuulAIbWZ3NrasOOqqAgAS8+YCAA/qGgIAASPkAgAFJ6TA=
Date: Thu, 17 Jun 2021 16:51:14 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5eedd48e04ec461289339777760669f2huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Bier] In reply to the formal complaints
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Jun 2021 16:51:25 -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,

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


On Wed, Jun 16, 2021 at 5:47 PM Michael McBride <<>> wrote:

Le 2021-06-11 à 13:40, Xiejingrong (Jingrong) a écrit :
> 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.

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

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.

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.



> 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 [<>] On Behalf Of Martin
> Vigoureux
> Sent: Monday, May 31, 2021 9:29 PM
> To:<>
> 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
> 1d5591fedc%7C1%7C0%7C637592689222267034%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
> p;sdata=ng78EEFJ0jNyOSdkvfv4Ic6xB3%2FpZkfY66Q%2BWdGZfIk%3D&amp;reserve
> d=0

BIER mailing list<>;;sdata=dcV1PufJOI0NEKjONjsDIKK3Ib7%2BBF7xiHasDrnGTQs%3D&amp;reserved=0

BIER mailing list<>