Re: [Bier] RFC8279: Request for authors to update RFC
Toerless Eckert <tte@cs.fau.de> Tue, 22 June 2021 10:29 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 73BAE3A1F94 for <bier@ietfa.amsl.com>; Tue, 22 Jun 2021 03:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 sMuwbeHtE18W for <bier@ietfa.amsl.com>; Tue, 22 Jun 2021 03:29:04 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3583A1F92 for <bier@ietf.org>; Tue, 22 Jun 2021 03:29:04 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 77C3154802F; Tue, 22 Jun 2021 12:28:55 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6A9484E7828; Tue, 22 Jun 2021 12:28:55 +0200 (CEST)
Date: Tue, 22 Jun 2021 12:28:55 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Greg Shepherd <gjshep@gmail.com>
Cc: BIER WG <bier@ietf.org>
Message-ID: <20210622102855.GE5939@faui48e.informatik.uni-erlangen.de>
References: <CABFReBpjD3V14P8CuO+_OHvZr=XX1c5Dm8SjB9pahJmrQJx5qQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABFReBpjD3V14P8CuO+_OHvZr=XX1c5Dm8SjB9pahJmrQJx5qQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/Y3a40PXfsnnbw8CAMn9bCEdRRxs>
Subject: Re: [Bier] RFC8279: Request for authors to update RFC
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: Tue, 22 Jun 2021 10:29:10 -0000
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 (https://slidetodoc.com/biertearch-ietf-103-bangkok-draftietfbiertearch01-toerless-eckert-ttecs/ , https://www.youtube.com/watch?v=UBZY4H6Ql_I&t=13s 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. Cheers Toerless 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 > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de
- [Bier] RFC8279: Request for authors to update RFC Greg Shepherd
- Re: [Bier] RFC8279: Request for authors to update… zhang.zheng
- Re: [Bier] RFC8279: Request for authors to update… Greg Shepherd
- Re: [Bier] RFC8279: Request for authors to update… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] RFC8279: Request for authors to update… Tony Przygienda
- Re: [Bier] RFC8279: Request for authors to update… Greg Shepherd
- Re: [Bier] RFC8279: Request for authors to update… Jeffrey (Zhaohui) Zhang
- Re: [Bier] RFC8279: Request for authors to update… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] RFC8279: Request for authors to update… Gyan Mishra
- Re: [Bier] RFC8279: Request for authors to update… Greg Shepherd
- Re: [Bier] RFC8279: Request for authors to update… Toerless Eckert
- Re: [Bier] RFC8279: Request for authors to update… Aijun Wang
- Re: [Bier] RFC8279: Request for authors to update… Greg Shepherd
- Re: [Bier] RFC8279: Request for authors to update… Toerless Eckert
- Re: [Bier] RFC8279: Request for authors to update… 'Toerless Eckert'
- Re: [Bier] RFC8279: Request for authors to update… zhang.zheng
- Re: [Bier] RFC8279: Request for authors to update… Mankamana Mishra (mankamis)