Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Greg Shepherd <gjshep@gmail.com> Mon, 08 March 2021 15:31 UTC

Return-Path: <gjshep@gmail.com>
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 4F1EE3A2C3B for <bier@ietfa.amsl.com>; Mon, 8 Mar 2021 07:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GQwLj1V_fqK2 for <bier@ietfa.amsl.com>; Mon, 8 Mar 2021 07:31:31 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5893A2C3F for <bier@ietf.org>; Mon, 8 Mar 2021 07:31:31 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id b7so15326724edz.8 for <bier@ietf.org>; Mon, 08 Mar 2021 07:31:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=l1WUoVY1f0YBnpDtv2Vy29+VJd+QAX9krytNt35nfGY=; b=btsQp46NQ5Sne8j/F3o0GPcbphvKwr1aptTyI0abuhB0TLeD7x8ZXlJcDbZp/DAW+9 tLspfQ2KUehDWOnE01Zgk8H1HOwr6CHATfXqgjUfNnu7srlE2FpDfU+CMAfz5nnmhBiU 8upx4LXahowPwQ1Y10uAE3fuJNO4QxNHDVmczbb9Klmn2BAj2tAmh3csikSlbGSBOr0X hQzxAE9SwGCtBB4Kzl8sWeT0tAKO8NkWgojIUlYVzqIw7pCN85PurGL0Pn6GBuz3oB+F ryKgf/eIP7xGuehRXLkPrdt64gsNzHNtl5tDImv3MeLFM538hzrg01knBJJLgu1pXDAe QlFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=l1WUoVY1f0YBnpDtv2Vy29+VJd+QAX9krytNt35nfGY=; b=ASIxVBCoCgS7GDWZ6a3kw8KHRGvKpncSfhP0CuQj2iocNR/FAwSjjdwN6DKY4sFulI 6wUENYkojB9fFXjlmWeopoiAcC0X3wgaP+qSgnfGtnv/SD3fSOQ7jNJPVEVKgcJ5IZFw kykq1O2JCGseb0iw37N/Etmkmjkmr6JtzbJafxubBM7642jTbVMZ+Hr8601nWByiyV2T RPu42dPZQXe8F4z4y6CZozv7nsA/hqhazbjt5iZwhMwKSn9wX4H8M5OF2amEVzBjK9g1 szvWyDf0fD3NU2EpXre8QHbmRzIAU+SHd3p6o7i3DiZLXUXiP2ZuEDmfhZWZCvAvf/BX TOqg==
X-Gm-Message-State: AOAM5315nRQd/j4NRMQbSMyrgQUKZJwDtI1d+1uBU1SeHQcOiACbuB2d zz86w9YwByN8dRsCpXrG44Dg2giBGuA0oN3/HJ4S7roSKhQ=
X-Google-Smtp-Source: ABdhPJzE9Xtqm56exH0QvNggaky+o4LgBwxY7MBJL3EAfLEWdZtUfzil1MG9ao1OfhshfL9ZcYN6AvA+kvwHwMAsayI=
X-Received: by 2002:a50:f314:: with SMTP id p20mr22471155edm.236.1615217487950; Mon, 08 Mar 2021 07:31:27 -0800 (PST)
MIME-Version: 1.0
References: <CABFReBodz5ko0wAZ_8vKgreWMLnCE_6O_qhKS_RGUbSAowEwfQ@mail.gmail.com> <CABFReBoDubmvGPCcHt8xi=3C3Ztp89TMvD1sOLX0EifadsU+pg@mail.gmail.com>
In-Reply-To: <CABFReBoDubmvGPCcHt8xi=3C3Ztp89TMvD1sOLX0EifadsU+pg@mail.gmail.com>
Reply-To: gjshep@gmail.com
From: Greg Shepherd <gjshep@gmail.com>
Date: Mon, 8 Mar 2021 07:32:04 -0800
Message-ID: <CABFReBomTJy_CuBNfU4NeJvBpeEBPx+J78eJ4LAAQa-vkrVNSA@mail.gmail.com>
To: BIER WG <bier@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009ab73a05bd0820f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/8nuWqGhqnHZFtkGSzpisQhTC__U>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6
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: Mon, 08 Mar 2021 15:31:37 -0000

Apparently my email filters are less than perfect. Stig pointed out that he
voted on March 4th but his vote wasn't in the tally. I confirmed receipt of
his vote and have updated the count as below. Will the authors please
update the draft name w/ the WG convention and Charis will accept. Thanks.

Name Yes No
gjshep@gmail.com x
tonysietf@gmail.com x
zzhang@juniper.net x
zhang.zheng@zte.com.cn x
hayabusagsm@gmail.com x
hooman.bidgoli@nokia.com x
michael.mcbride@futurewei.com x
xiejingrong@huawei.com x
adrian@olddog.co.uk x
hayabusagsm@gmail.com x
ice@braindump.be x
mankamis@cisco.com x
gregimirsky@gmail.com x
qinzhuangzhuang@chinaunicom.cn x
zhuyq8@chinatelecom.cn x
xiao.min2@zte.com.cn x
zhangzhe22@huawei.com x
xiong.quan@zte.com.cn x
gengxuesong@huawei.com x
peng.shaofu@zte.com.cn x
stig@venaas.com x
---------------------------------------------------
TOTAL: 13 8

Thanks,
Shep
(Chairs)

On Sun, Mar 7, 2021 at 8:39 AM Greg Shepherd <gj
shep@gmail.com> wrote:

> 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
> gjshep@gmail.com x
> tonysietf@gmail.com x
> zzhang@juniper.net x
> zhang.zheng@zte.com.cn x
> hayabusagsm@gmail.com x
> hooman.bidgoli@nokia.com x
> michael.mcbride@futurewei.com x
> xiejingrong@huawei.com x
> adrian@olddog.co.uk x
> hayabusagsm@gmail.com x
> ice@braindump.be x
> mankamis@cisco.com x
> gregimirsky@gmail.com x
> qinzhuangzhuang@chinaunicom.cn x
> zhuyq8@chinatelecom.cn x
> xiao.min2@zte.com.cn x
> zhangzhe22@huawei.com x
> xiong.quan@zte.com.cn x
> gengxuesong@huawei.com x
> peng.shaofu@zte.com.cn 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.
>       - BIER layer does not care what transport is used. BIER packets are
>       payloads of L2 or tunnels (e.g. IPv6 “next header” is BIER).
>       - BIER layer does not care what payload it is carrying
>    - Supports all requirements w/o any new procedures:
>       - 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.
>
>       - SRv6 based services over BIER can be achieved by imposing a BIER
>       header after imposing IPv6 header used for SRv6 service.
>       - 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
>       - 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.
>       - 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:
>       - BIER header as option in IPv6 DOH
>       - IPv6 encapsulation from BFIR to BFER. IPv6 is used even between
>       directly connected BFRs
>    - Service over BIER tightly coupled with SRv6 (protocol/layer
>    dependency)
>       - 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 <gjshep@gmail.com> 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)
>>
>