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

Toerless Eckert <tte@cs.fau.de> Mon, 28 June 2021 23:22 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 598A43A1B06 for <bier@ietfa.amsl.com>; Mon, 28 Jun 2021 16:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 u_6zgOrWnyC8 for <bier@ietfa.amsl.com>; Mon, 28 Jun 2021 16:22:24 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 825533A1B08 for <bier@ietf.org>; Mon, 28 Jun 2021 16:22:24 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BEE2A54806A; Tue, 29 Jun 2021 01:22:17 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id B96B74E78C5; Tue, 29 Jun 2021 01:22:17 +0200 (CEST)
Date: Tue, 29 Jun 2021 01:22:17 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Greg Shepherd <gjshep@gmail.com>
Cc: BIER WG <bier@ietf.org>
Message-ID: <20210628232217.GA5535@faui48e.informatik.uni-erlangen.de>
References: <CABFReBpjD3V14P8CuO+_OHvZr=XX1c5Dm8SjB9pahJmrQJx5qQ@mail.gmail.com> <20210622102855.GE5939@faui48e.informatik.uni-erlangen.de> <CABFReBo9HBbiaj5naFqFoQKu5ZmOvoy+XGKR5hA_ixz+D9UePg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABFReBo9HBbiaj5naFqFoQKu5ZmOvoy+XGKR5hA_ixz+D9UePg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/cbdqfyi2X2tLQeaqJa3E3QQz9q0>
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: Mon, 28 Jun 2021 23:22:29 -0000

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 <tte@cs.fau.de> 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
> > > BIER@ietf.org
> > > https://www.ietf.org/mailman/listinfo/bier
> >
> >
> > --
> > ---
> > tte@cs.fau.de
> >

-- 
---
tte@cs.fau.de