Re: [Bier] RFC8279: Request for authors to update RFC Tue, 29 June 2021 03:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 808173A22D1 for <>; Mon, 28 Jun 2021 20:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rw2ZHzJ2zBok for <>; Mon, 28 Jun 2021 20:40:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D43413A22D5 for <>; Mon, 28 Jun 2021 20:40:03 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id AF878897B86BF63FD022; Tue, 29 Jun 2021 11:40:01 +0800 (CST)
Received: from ([]) by with SMTP id 15T3dk7n088649; Tue, 29 Jun 2021 11:39:46 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Tue, 29 Jun 2021 11:39:46 +0800 (CST)
Date: Tue, 29 Jun 2021 11:39:46 +0800 (CST)
X-Zmail-TransId: 2afa60da9602b36dbd0d
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>, <>
Cc: <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 15T3dk7n088649
Archived-At: <>
Subject: Re: [Bier] =?utf-8?q?RFC8279=3A_Request_for_authors_to_update_RFC?=
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: Tue, 29 Jun 2021 03:40:09 -0000

Yes. Thanks Toerless very much for your suggestion!
Will consider your suggestion carefully.
Welcom to join our work! :-)
Best regards,

收件人:Toerless Eckert;
抄送人:BIER WG;
日 期 :2021年06月29日 01:41
主 题 :Re: [Bier] RFC8279: Request for authors to update RFC
BIER mailing list

Thanks Toerless. All good suggestions, and valuable input. I'm certain Sandy will welcome your help.


On Tue, Jun 22, 2021 at 3:29 AM Toerless Eckert <> wrote:
Greg, *:
I would like to help,... but better not promise more than best effort cycles, which may be rare
under presence of more businss criticial cycles.
I am not quite clear yet, what specifically would be in our out of scope of such
an rfc8279bis? effort. I remember that when we updated PIM-SM for its 'bis RFCs,
someone had collected a long list of issues/improvement suggestions. Maybe
we should have a wiki page on the ietf BIER wiki to allow WG members to contribute
suggestions for improvements to make it easier to track possible work items ?
Working through bier-te-arch for updating to ADs review last weeks, i revisited
some parts of 8279 to better align with them, so some thoughts to help
such a list somewhat cenric to that:
1. Pictures!
Section 4 might benefit from a picture visualizing the layerin,
maybe the picture in bier-te-arch could serve as a starting point.
2. Explicitly call out control vs. forwarding plane
Section 4.2 does not explicitly distinguish between what of its bullet
point list is BIER layer control plane vs. BIER layer forwarding plane.
Maybe separating would be nice.
3. distributed vs. decentralized/centralized BIER layer control plane
The whole document is written (IMHO) so as to imply that the control plane
is distributed. This is definitely what we defined so far in the WG
(with ISIS, OSPF), and IMHO the biggest benefit of BIER compared
to e.g.: BIER-TE which because of its need to engineer the trees
more naturally depends on a controller.
Nevertheless, i remember Tony and others to reiterate in past meetings that we could
also build/implement BIER purely with controller driven conrol plane.
If it is indeed a goal to open hat door, than such an option might be better documented.
Example of text that seems to exclude a solely controller based BIER layer control plane:
(4.2) "Protocols and procedures that a given BFR uses to advertise, to all other BFRs in the same BIER domain"
4. Need for / Role of BIRTs
If controller driven BIER is of interest, IMHO, one corollary is that
the BIRTs may be optional, because the way i see it, they really are
the data structure populated by the local control plane (IGP/BGP), whereas
a controller based control plane may be beter off directly populating
the BIFTs. I think it might be easier though to add such thoughts to
the architecture when we have worked through such thoughts by being
further along with the BIER yang models (i already tried to help with
the object model for the BIRT there, i don't think we have even tried
to define the real BIFT entries in the yang model).
aka: like in unicast/ip-multicast, BIRT to me would live solidly
in the BIER layer control plane, required maybe only with distributed
control plane options, whereas he BIFT is the control plane API into the BIER layer
forwarding plane, aka: mandatory for any BIER forwarder).
5. Acceptable F-BM for BIFT (impacts implementations)
If/when we define any yang model for the BIFT, IMHO we would need to
resolve the question if/what F-BM would have to be acceptable via such
an API. This would have an impact on the forwarding implementations.
See slide 8 of my IETF103 preso ( , at 1:31:00 )
6. Which layer does the IGP live in ?
One of the corollaries not explicitly called out for in 8279 is that
AFAIK, the IGP itself seems to live in the conrol plane of the routing
underlay, whereas the BIER extensions of the IGP would live in the
control plane of the BIER layer.
Aka: the fact that a single control plane (IGP) protocol may stretch across
the layers of the BIER architecture may be something to explicitly call out,
because this may be somewhat counterintuitive to readers oherwise.
6. API between Flow overlay and BIER layer on BFIR and BFER
If/when we wanted to ensure that Flow overlay and BIER layer could be
developed independendly on BFIR/BFER (think linux where BIER is implemented
once and different apps/overlays want to use it), we may want to have a
somewhat more formalized abstract API definition for the BIER layer.
Thought experiment: I build on linux BFIR/BFER some flow overlay based on
an available MPLS based BIER layer implementation. Then comes along
draft-ietf-bier-non-mpls-bift-encoding an the BIER layer is extended to
support e.g. BIER directly over ethernet. Q: should/could we have
defined upfront the BIER-layer to flow overlay API such that i would not
have to go back updating/modifying the flow overlay implementation ?
I think that would be lovely. Have we given implementers all the help we
shuold to enable that ?
This goes primarily back to do we expose BIFT-id to flow overlay,
and what happens if such in hat draft its semantic changes.
On Sat, Jun 12, 2021 at 06:05:16AM -0700, Greg Shepherd wrote:
> A big "thank you" to all WG members who have worked so hard to get BIER to
> where it is today. And to no surprise, our work is not done. The following
> bullet points are from the Chairs' technical summary previously sent to the
> list:
> ??? BIER encoding is specified in RFC8296
> ??? Alia Atlas: ???IANA code-points don???t change.  This is the reason why BIER
> began as experimental - narrow
>         point in hourglass???
> ??? The encoding at the ???narrow point of the hourglass??? ??? the forwarding
> plane ???  is the foundation from which
>         the rest of the architecture grows.
> ??? This was the position of the IESG and the BIER WG ADs at the time of the
> original WG Experimental Charter.
> ??? This is admittedly historic/institutional knowledge of those involved in
> the WG from the beginning. But it is also
>         a core tenet of the layered and scalable architecture of the
> Internet and was erroneously assumed as
>         well-understood by the original WG contributors. The WG needs to
> update the BIER architecture to make this
>         responsibility clear for all future contributors.
> RFC8279 began as a draft at the very beginning of the WG. It has since been
> made clear that the authors at that time had assumed the importance of the
> forwarding plane as the foundation of architecture was well understood by
> the community at large. That no longer seems to be the case. Additionally,
> the draft of RFC8279 began before the draft of RFC8296 was complete, and
> even before the assignment of the IEEE BIER ethertype.
> This is a call for volunteers to update RFC8279 to better define BIER at
> the forwarding plane, and clarify how IETF-standard encapsulation
> mechanisms can be used to transit BIER packets, while preserving the core
> tenet of a layered and scalable architecture of the Internet.
> If you would like to tackle this update, please reply to this thread.
> Thanks,
> Greg
> (Chairs)
> _______________________________________________
> BIER mailing list