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

Greg Shepherd <> Sun, 07 March 2021 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7ECF3A18E4 for <>; Sun, 7 Mar 2021 08:38:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zb0Km_ia8MXj for <>; Sun, 7 Mar 2021 08:38:34 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B39F93A18E3 for <>; Sun, 7 Mar 2021 08:38:33 -0800 (PST)
Received: by with SMTP id w1so15305261ejf.11 for <>; Sun, 07 Mar 2021 08:38:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=d2kVlztu9m3acsSAzPAvcGBaNLtRAeaYB/lL3bbbU4Y=; b=Ggt4RXKwrGKNHumyMAuXKSA+mFJWgdnPLk5kFWNfPAeCAs70UiQsNtGKdBj+qPryOZ 3dmyqRweVQTYvtM7UmHu3XYiC1nY098tUN+G4YcrTFdt2khze9OMTUh3+5b+nB9/9WGl P2op8+uwd6jm3IsN8B1DUCax3AE9PlVF1GHBTqymthNEWs/hRj+FgcdbcU3QLisHrDXz 97QYvPBxhrKKPN3AcpzhnnG1arnNCAXxI9Sx878mJfqGlkBf7XnRmzo5I+YoF9eUKq/h fqFyfQcYdmj6ltcWN1h2jdNlAIsAgjEHkhl2PA7Yq7FF6TNn+9U3l0e2C25ELvagz1OY 7Q3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=d2kVlztu9m3acsSAzPAvcGBaNLtRAeaYB/lL3bbbU4Y=; b=uG+VPrRiEqL1SlEFwpzwAx02c5BwUPUXrLfCn1FJXLAsa1UFKqM7p59J7/m+lkKhG0 tbGb51CH8Vb5JFHDPuqC9pj1EnHjO91583rZJfAn2JRhq9P/mhFQ/NtwPKIrrNXHbx2T obmftIgx2GjSPqgEk2ri4u+KWcb20dxPx9d3sEpvgpgUjyfMovCml5oi9hjzBozHG5kR QFL4BMLG+4hdYPIINCjzRmeKFzrEjhCNKZGMPdD9Ty9CnOC8l28sdMKFvRoxneLmw2rf g3k2LnDu4CHX19AxWiqVcnIv4Y75jliede1mrixRS//fR3+oJiAg5p72i9HFTVZodIzM B1Xw==
X-Gm-Message-State: AOAM533cyFNf697DUXWf8pzzn2Nb9LGn767lCAB7TOy/3QEN06riYaJb Au4HSSqkF8+i2hvNTW/9esYie6yVPSggh3lCzWDuc5UbzRo=
X-Google-Smtp-Source: ABdhPJw6wiitb16ZdyVa2wWD6kXJynbVEmSUd2IBFY1ANjH1MdKZGfNV0wMmPnUC5Gby4Oq3cuWgw13OcwXMp1jzYCs=
X-Received: by 2002:a17:906:71d3:: with SMTP id i19mr11592282ejk.347.1615135110652; Sun, 07 Mar 2021 08:38:30 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Shepherd <>
Date: Sun, 7 Mar 2021 08:39:05 -0800
Message-ID: <>
To: BIER WG <>
Content-Type: multipart/alternative; boundary="00000000000088e4f105bcf4f2b2"
Archived-At: <>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6
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: Sun, 07 Mar 2021 16:38:39 -0000

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

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

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
         - RFC8085 UDP Usage Guidelines, Section 3.2 - " 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
      - 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

On Thu, Feb 25, 2021 at 8:37 AM Greg Shepherd <> 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.
> Please reply to this thread with your support/opposition of WG adoption of
> the draft.
> Thanks,
> Shep
> (Chairs)