Re: [Bier] In reply to the formal complaints

zhang.zheng@zte.com.cn Fri, 18 June 2021 06:45 UTC

Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9593A3F40 for <bier@ietfa.amsl.com>; Thu, 17 Jun 2021 23:45:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6EuYebqAMyN for <bier@ietfa.amsl.com>; Thu, 17 Jun 2021 23:45:14 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2D73A3F3F for <bier@ietf.org>; Thu, 17 Jun 2021 23:45:13 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 76AD6AF315544605D210; Fri, 18 Jun 2021 14:45:00 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 79A36B411FD0E9E1C2D6; Fri, 18 Jun 2021 11:10:42 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id 15I3ASov019160; Fri, 18 Jun 2021 11:10:28 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Fri, 18 Jun 2021 11:10:27 +0800 (CST)
Date: Fri, 18 Jun 2021 11:10:27 +0800 (CST)
X-Zmail-TransId: 2afb60cc0ea3235b88df
X-Mailer: Zmail v1.0
Message-ID: <202106181110279241465@zte.com.cn>
In-Reply-To: <5eedd48e04ec461289339777760669f2@huawei.com>
References: a2a82830-faf2-0992-c4bf-b02cdb8e6e4c@nokia.com, 6509bf2874d94e0ca49d6a2a84bd9fed@huawei.com, 913d606b-31cf-18ab-1ed9-46918283a741@nokia.com, BYAPR13MB2582B3EBCD5FB7F1C635A72FD00E9@BYAPR13MB2582.namprd13.prod.outlook.com, CABFReBoW7YRPdDVeUWAva8atz4UtfhJoBPnW4orUJ9U41XFFCw@mail.gmail.com, 5eedd48e04ec461289339777760669f2@huawei.com
Mime-Version: 1.0
From: <zhang.zheng@zte.com.cn>
To: <lizhenbin@huawei.com>
Cc: <gjshep@gmail.com>, <mmcbride@futurewei.com>, <xiejingrong@huawei.com>, <bier@ietf.org>, <martin.vigoureux@nokia.com>, <zzhang@juniper.net>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 15I3ASov019160
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/jp_J_LjNtuuHVQ8vV7_RFWvClsA>
Subject: Re: [Bier] =?utf-8?q?In_reply_to_the_formal_complaints?=
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2021 06:45:20 -0000

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
收件人:gjshep@gmail.com;m00759202;
抄送人:Xiejingrong (Jingrong);bier@ietf.org;Martin Vigoureux;
日 期 :2021年06月18日 00:51
主 题 :Re: [Bier] In reply to the formal complaints
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

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 neces
 sary.
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:bier-bounces@ietf.org] On Behalf Of Greg Shepherd
Sent: Thursday, June 17, 2021 1:08 PM
To: m00759202 <mmcbride@futurewei.com>
Cc: Xiejingrong (Jingrong) <xiejingrong@huawei.com>om>; bier@ietf.org; Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: [Bier] In reply to the formal complaints

Inline:

On Wed, Jun 16, 2021 at 5:47 PM Michael McBride <mmcbride@futurewei.com> wrote:
Howdy,

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.

Greg

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.
> 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:bier-bounces@ietf.org] On Behalf Of Martin
> Vigoureux
> Sent: Monday, May 31, 2021 9:29 PM
> To: bier@ietf.org
> 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
> BIER@ietf.org
>  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
BIER@ietf.org
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

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier