[Bier] Formal Complaint about this Adoption Call //RE: Call For Adoption: draft-zhang-bier-bierin6

["Xiejingrong (Jingrong)" <[e-mail]>]

Dear Alvaro,

This email is to formally object WG adoption of draft-zhang-bier-bierin6, which violates IETF consensus process as defined in RFC 7282, and goes against the suggestions of how to handle document adoption in RFC 7221, for the following reasons:

1.Control voting in BIER ML.

WG chairs started a WG adoption poll without deadline and rule on February 25. For this everyone assume that normal process apply: Normal is to get rough consensus; Normal is for two week poll to March 11 or 12; Normal is when IETF meeting comes make extra time for polls and last calls because everyone is so busy.
Refer to: https://mailarchive.ietf.org/arch/msg/bier/m3XbUvnHSSj2D2wgbnurzFsoARc/

However WG chairs cut off the WG adoption poll when support had more votes and announce the result to represent “majority” on March 7.
Refer to: https://mailarchive.ietf.org/arch/msg/bier/6zfgYZ3kQU2mTiZp4YRdTQYo6RQ/

We protest against WG chairs playing such tricks to adopt the document they want through their positions in the Working Group.

2.Concealment and flaw in vote counting

WG chairs added 2 votes on support side by counting 2 WG chairs without their response to WG adoption poll in the ML (either as individual or as WG chairs). WG chairs are entitled to technical opinion, but must not influence difficult and contentious decision.
Refer to: https://mailarchive.ietf.org/arch/msg/bier/6zfgYZ3kQU2mTiZp4YRdTQYo6RQ/

One person from each side was not counted in the counting results:
Refer to: https://mailarchive.ietf.org/arch/msg/bier/XWawNW0aFBkOI7LCDzd4mub-fa4/
Refer to: https://mailarchive.ietf.org/arch/msg/bier/xIcb28Fd51CYPiiS8LjHF5wftFc/

3.Ignore technical/process concerns raised in the ML deliberately.

There are significant technical problems and immature features in the contents of draft-zhang-bier-bierin6 which have been discussed in ML but without proper response:
Refer to:
RFC8986 violation
https://mailarchive.ietf.org/arch/msg/bier/EgpMcmMcn7VY7QCsRG74VO7qytw/
Can’t support MVPN properly
       https://mailarchive.ietf.org/arch/msg/bier/uuknP1l9blihkf1bVn6zui3Pjtw/
Can’t support Fragmentation/ESP properly
https://mailarchive.ietf.org/arch/msg/bier/3cNQg9U0R6I2TffbU7_iFQJNCyc/
Concern about IPv6 alignment
https://mailarchive.ietf.org/arch/msg/bier/3qOKjAOEwGA6kYRr6a2EEtN1li8/

The issue of the working group process was also raised several times in the ML but WG Chairs never responded.
Refer to: https://mailarchive.ietf.org/arch/msg/bier/S3JLLivj_udSTbViB1VeUtMl0_c/
       https://mailarchive.ietf.org/arch/msg/bier/Kr48rkmW0wEpv_s0jasyGpg_mTs/
       https://mailarchive.ietf.org/arch/msg/bier/8sUA_ZfeoQyIGojPu0vl6s7voJw/
       https://mailarchive.ietf.org/arch/msg/bier/cXpa9NyaW7QdJMYL94lOpCFT19g/

4.In defense of BIERv6, as response to the email from WG chair with clear bias.

BIERv6 and BIERin6 are competitive solutions for the same topic, and the chair always stand in his own opinion with the BIERin6 side (where the other chair and the secretary are authors).

All of the following claims made by WG chairs are misleading:

1)       The claim that BIERin6 “is supported under the BIER WG charter”. à Both solutions are under BIER WG charter based on previous discussion. Charter shouldn’t be used as justification of only BIERin6 adoption.



Alia Atlas, when she was AD, had clarified the charter text as: “natively - as opposed to over MPLS or Ethernet.”

Refer to:  https://mailarchive.ietf.org/arch/msg/bier/aZpcpsaOpMjacZ2plmbeIQG9oLg/

Alvaro clarified that “while a Charter is used to provide scope and focus, it must not be used as justification for doing work in the absence of discussion and consensus.”

Refer to: https://mailarchive.ietf.org/arch/msg/bier/rl3EgsKMf6WU2pTUgcmbl84Ztdk/

It shows that WG chairs did not listen to voice in the ML, even from the AD.


2)       The claim that BIERin6 “supports all requirements w/o any new procedures” à There are new procedures introduced by BIERin6 specified in draft-zhang-bier-bierin6, including new mechanism defined in draft-zzhang-tsvwg-generic-transport-functions-00 and new “MPVN IPv6 header or DA”.

Refer to: https://tools.ietf.org/html/draft-zhang-bier-bierin6-09

While BIERv6 can support all of the “requirements” better than BIERin6, it is always ignored by WG chairs.


3)       The claim that BIERin6 is an “Existing generic BIER-non-MPLS solution” à It is not true. Both solutions should be evaluated from technical aspects rather than “announce” one of the solution as an “existing solution”, not to mention BIERin6 is not.

It has been questioned several times in the mailing list, but the BIERin6 authors never answered how/why it is “an existing solution” and the chairs insisted to ignore these questions:

Refer to: https://mailarchive.ietf.org/arch/msg/bier/JvmQOxLUMVhdEGLeBgRvfIIn4Us/
https://mailarchive.ietf.org/arch/msg/bier/4WkDcTmdlhCxaxgv2UuK70AP0no/


4)       The claim “Given the long-time debate on BIERin6 vs. BIERv6, it is critical to have a standard RFC to document this generic BIER-non-MPLS solution for IPv6 networks” à There is a clear fallacy in the cause and effect relationship in this sentence. Long time debate means technical disagreement existing in the ML, but the chairs have no capability to handle this except for adopting the document he preferred without hearing, thus intensifying the conflict. A suggestion was made on the ML to adopt both solutions as Experimental, but chairs never made any response.



* It is very abnormal to find that: when BIERv6 requested WG adoption before IETF108, it was denied by WG chairs and even not allowed to present in the meeting, just as the discussions in ML didn’t exist; when there is significant progress in BIERv6 with implementation status updated in the document, WG chairs suddenly find it is “critical” to have the other document become a standard RFC.

Refer to: https://mailarchive.ietf.org/arch/msg/bier/SVOUv4YTtWNMdZxb9W4XTrvl7pA/


5)       The claim that “the authors are unwilling to listen to technical feedback from the WG”. à All the comments from the chairs and WG members are carefully addressed in each version of BIERv6.

Refer to: https://mailarchive.ietf.org/arch/msg/bier/uoyQEdw4L9FfYrSIufdbHAW1lIc/
https://mailarchive.ietf.org/arch/msg/bier/OmUClahtShxLdWzR8txJP09FmWE/


6)       The claim BIERin6 is better due to its compatibility of “BIER Architecture” à The “BIER architecture” has already been included in draft-ietf-bier-ipv6-requirements draft, and BIERv6 could satisfy these “BIER Architecture” requirements.

Refer to: https://tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-09
https://mailarchive.ietf.org/arch/msg/bier/uoyQEdw4L9FfYrSIufdbHAW1lIc/

All these behaviors above undermined the technical impartiality of the Working Group and the spirit of the IETF seriously.
It is requested that AD:
Stop and declare result invalid of draft-zhang-bier-bierin6 WG adoption poll.

Thanks,
Jingrong


From: BIER [mailto:[e-mail]] On Behalf Of Greg Shepherd
Sent: Monday, March 8, 2021 12:39 AM
To: BIER WG <[e-mail]>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Thank you to all the authors, participants in the discussion contributing technical arguments, and to everyone who commented and voted. Special thanks to Jeffrey for keeping the technical discussions honest and productive.

The call to adopt has passed. Comments to the list regarding the vote, this draft and others below. The votes are as follows:

Name

Yes

No

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

[e-mail]<mailto:[e-mail]>

x

---------------------------------------------------

TOTAL:

12

8


This work is supported under the BIER WG charter:

<>
7) BIER in IPv6 : A mechanism to use BIER natively in IPv6 may be
standardized if coordinated with the 6MAN WG and with understood
applicability.
</>

The call for adoption of draft-zhang-bier-bierin6 drew another round of comments and comparisons to draft-xie-bier-ipv6-encapsulation, so I will address the comments and comparisons here.

Technical Summary
Summary of BIERin6:

·         Existing generic BIER-non-MPLS solution – BIER packets transported over L2 links or any tunnels (including IPv6 tunnels) between two BFRs.
·         IPv6 tunnels for BIER transport is typically multi-hop, either for getting over BIER incapable routers or for FRR purposes.
·         One-hop IPv6 tunnels can be optionally used between directly connected BFRs if L2 cannot indicate next header is BIER (either due to lack of code points or because existing hw cannot handle a new code point)
·         Clean layered, standards-based, generic architecture: BIER payload, BIER, and BIER transport are completely independent.
o    BIER layer does not care what transport is used. BIER packets are payloads of L2 or tunnels (e.g. IPv6 “next header” is BIER).
o    BIER layer does not care what payload it is carrying
·         Supports all requirements w/o any new procedures:
o    BIER is L2.5, like MPLS, and has no fragmentation requirement as part of the BIER architecture. Network fragmentation of UDP packets is not recommended.
·         RFC8085 UDP Usage Guidelines, Section 3.2 - "..an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination.  Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191][RFC1981] [RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation."
·         Optional fragmentation/ESP between BFIR/BFER, if needed, can be achieved by first imposing IPv6 header for fragmentation/ESP and then imposing BIER header.

o    SRv6 based services over BIER can be achieved by imposing a BIER header after imposing IPv6 header used for SRv6 service.
o    In both cases, IPv6 (for the purpose of fragmentation/ESP/service) is treated as BIER payload, but that is different from the IPv6 used for tunneling between BFRs.
·         Reason for standardization
o    Need code point for BIER as “IPv6 next header” (for IPv6 tunneling). The same code point is also “IP Protocol” if IPv4 tunneling is used in an IPv4 non-MPLS network.
o    Given the long-time debate on BIERin6 vs. BIERv6, it is critical to have a standard RFC to document this generic BIER-non-MPLS solution for IPv6 networks.

Summary of BIERv6:

·         BIER and IPv6 tightly coupled for BIER/lower layer:
o    BIER header as option in IPv6 DOH
o    IPv6 encapsulation from BFIR to BFER. IPv6 is used even between directly connected BFRs
·         Service over BIER tightly coupled with SRv6 (protocol/layer dependency)
o    But with different SRv6 behavior – Source address instead of DA is used on BFER for service delimiting, which has its own complications

Conclusion:A cleanly layered, standards-based, generic solution (draft-zhang-bier-bierin6) vs. a solution that creates a BIER protocol dependency with IPv6/SRv6 but with changes in SRv6 service handling (draft-xie-bier-ipv6-encapsulation)

Some additional comments about the drafts, the WG process, and the impact to the existing BIER Standards-Track(ST) Architecture:

From rev0 of draft-xie-bier-ipv6-encapsulation, it was explained to the authors that the encoding and encapsulation are completely separate tools and need to be addressed as such. There are numerous IETF ST encapsulation tools available, and any proposed new encapsulation will require justification - ie, some use-case that cannot be solved any other way, or some unique value offered by a new proposal. No unique use-case has been adequately described.  It has been pointed out countless times that the name of the draft is misleading and should be changed to more accurately describe/represent the intent of the draft, ie - encoding. Despite numerous requests, the name has remained, and the text of the draft continues to obfuscate the distinction:

draft-xie-bier-ipv6-encapsulation, 1, Introduction:

This document proposes a BIER IPv6 encapsulation for Non-MPLS IPv6

   Networks, defining a method to carry the standard Non-MPLS BIER

   header (as defined in [RFC8296]) in the native IPv6 header.  A new

   IPv6 Option type - BIER Option is defined to encode the standard Non-

   MPLS BIER header and this newly defined BIER Option is carried under

   the Destination Options header of the native IPv6 Header [RFC8200].
After rev 1 or 2 it may be assumed there is some remaining confusion, miscommunication, or misunderstanding. But after rev10 without the authors addressing the issue, it can only be concluded that the obfuscation is intentional, and the authors are unwilling to listen to technical feedback from the WG.

The BIER WG began as experimental because the work required fundamental changes to the Internet architecture by defining a new forwarding plane, which includes a BIER encoding header and associated BIER architecture. This encoding has now been adopted as ST. Any additional encoding methods would only serve to errode the standards work of the BIER WG and potentially undo the past 8 years of work. This high bar that was set by the IAB and our AD (Alia Atlas), at the time. The bar will not be lowered. An encapsulation method as described in draft-zhang-bier-bierin6 is in no way experimental in that it uses the ST BIER encoding and existing methods and registries.

Any new encoding and/or forwarding plane must face the same level of scrutiny. To date, the authors of draft-xie-bier-ipv6-encapsulation have failed to offer any compelling, unique use-case where a new encoding is required. As a further complication, the proposal creates a dependency between SRv6 and BIER. Protocol dependencies have come and gone in the IETF, and in every case I've found, they have proven to be crippling at best, if not outright monumental failures. Any proposal which requires changes to the forwarding plane, protocol dependencies, and potential erosion of the BIER Architecture and established ST work has an even higher bar to clear. The authors to date, have shown no intention to address these concerns with clear technical reasoning.

- Shep
(Chairs)

On Thu, Feb 25, 2021 at 8:37 AM Greg Shepherd <[e-mail]<mailto:[e-mail]>> wrote:
Thank you all for the active discussion that brought us to consensus. This draft now addresses all of the points of discussion for the solution.

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/

Please reply to this thread with your support/opposition of WG adoption of the draft.

Thanks,
Shep
(Chairs)