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

[Aijun Wang <[e-mail]>]

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