Re: [Bier] RFC8279: Request for authors to update RFC

['Toerless Eckert' <[e-mail]>]

Thanks. Added to reading list.

given how you have named this -pce- (and not -bier-), it will not show up automatically
on the BIER WG datatracker list of associated documents. If this is
meant to be read by BIER folks, please ask BIER chairs to have this
doc associated with BIER on datatracker (few clicks for a chair on datatracker!)

Cheers
    Toerless

On Mon, Jun 28, 2021 at 11:44:02AM +0800, Aijun Wang wrote:
> Hi, Toerless:
> 
> Related to your 3rd point(centralized BIER layer control plane), we have
> summited one draft
> https://datatracker.ietf.org/doc/html/draft-li-pce-pcep-extension-multicast-
> management-00.txt to cover this topic.
> The updated version of this draft will be provided soon in these days, and
> we would like to make one introduction for this draft in the coming IETF
> meeting.
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]> On Behalf Of Toerless
> Eckert
> Sent: Tuesday, June 22, 2021 6:29 PM
> To: Greg Shepherd <[e-mail]>
> Cc: BIER WG <[e-mail]>
> Subject: Re: [Bier] RFC8279: Request for authors to update RFC
> 
> 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-to
> erless-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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bier
> 
> 
> --
> ---
> [e-mail]
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
[e-mail]