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

[Toerless Eckert <[e-mail]>]

Thanks, Greg.

Would be great if any work towards bis'ing the RFC would be set up openy
enough such that this type of help/support will continue to be possible
(e.g.: if there is a DT style approach, pls. make it open).

Cheers
   toerless

On Mon, Jun 28, 2021 at 10:40:29AM -0700, Greg Shepherd wrote:
> Thanks Toerless. All good suggestions, and valuable input. I'm certain
> Sandy will welcome your help.
> 
> Cheers,
> Greg
> 
> On Tue, Jun 22, 2021 at 3:29 AM Toerless Eckert <[e-mail]> 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 (
> > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/bier
> >
> >
> > --
> > ---
> > [e-mail]
> >

-- 
---
[e-mail]