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

Greg Shepherd <> Mon, 28 June 2021 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BAA1E3A122B for <>; Mon, 28 Jun 2021 10:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8pMeEWaU9Oko for <>; Mon, 28 Jun 2021 10:40:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 934233A1229 for <>; Mon, 28 Jun 2021 10:40:42 -0700 (PDT)
Received: by with SMTP id l24so2021412ejq.11 for <>; Mon, 28 Jun 2021 10:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=QsH7Ia9muWPdEthPfg9sr9tf/uh148N39h99cFmZb4Y=; b=JOJcaPMffkw3sau4Zo+IpmSyuXpUlhFlzXHtQkSuIg0YrUnP/cMjq5uFTZs43bMT7M 8u26Jm1nz+A/MJ/wriXGWHRTw0bQAy8WoIod2peA6L/bPuPYjK1s95em6qhMbnwE4hBV 5eKYb9a40WYcOct4UCt+13ztoW4rJSPdviK0ZsTBuyBaZX4g7XJVFl1031p4GpPQ++P5 kuxARYa4gqdZ+UhXn66oCQ1INI75A6o+k/Xy6KwS7cOGCf4nry9LUp9c7ioK2OKspEf5 F42r018b26HipCKSgvJUEpcUSJggktM4m01w5OjXMkgx43EblHgz/5HEeYlRu5idHR37 j0OQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=QsH7Ia9muWPdEthPfg9sr9tf/uh148N39h99cFmZb4Y=; b=fpyTHqXpD/EVfmd2xNCgcTQUhgizArz5urEKu68dc1uDYP3VJ1z6v7MUk84SRWFur+ JljP8f7e1FI/UphdfobeXRHea8Jx/HMmtekLGJzqvYYN7IRz1BmwEpMtnKhcp7nylbze tK7T13Aq2GadhhqZVh71XkuZjIhdpNUsg7SCMZ2wpicwh7fkiK+eBrNldxtcDabGY7wX 4lHyyGCRVGPKpCy7gUQMaiiAhiZYx4At+JCz0EfCCIRrGPEkIZJmFHmB00UVQ/5Fx8Y1 CrRPU6s86goYS28jyt8vkocWerHlmZtsJJHUy6J/8Il8BFIfSmosvNHK+IaONcolIpQv 5mGQ==
X-Gm-Message-State: AOAM530uN6iJRCKRdd/v5e/pP8EvwtpK5vfS2+aQbnpnr/16lYN89vhf aC2nQ11PgKRIIRXS9g5izxOpEFnjKTNaX99fu5I=
X-Google-Smtp-Source: ABdhPJxleEzeXyuGhkGZg/EeyXHCToTaFmiCIvqXarH1872wKU9i3T8CpCWh7RIqYnAtlIrXvXTrtznJlRO4XGjvbvU=
X-Received: by 2002:a17:906:6b8a:: with SMTP id l10mr25077302ejr.125.1624902040983; Mon, 28 Jun 2021 10:40:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Greg Shepherd <>
Date: Mon, 28 Jun 2021 10:40:29 -0700
Message-ID: <>
To: Toerless Eckert <>
Cc: BIER WG <>
Content-Type: multipart/alternative; boundary="000000000000f29b7305c5d6fca2"
Archived-At: <>
Subject: Re: [Bier] RFC8279: Request for authors to update RFC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Jun 2021 17:40:48 -0000

Thanks Toerless. All good suggestions, and valuable input. I'm certain
Sandy will welcome your help.


On Tue, Jun 22, 2021 at 3:29 AM Toerless Eckert <> 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 (
> , 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
> >
> >
> --
> ---