The BIER (Bit Index Explicit Replication) Working Group has defined an architecture [RFC 8279] for multicast forwarding that uses an encapsulation [RFC 8296] that can be used on MPLS or Ethernet transport.
The BIER-WG is now chartered to produce Standards Track RFCs, including the status update for RFCs 8279 and 8296.
The BIER working group's original charter required the publication of an Informational RFC describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms as well as an analysis of the impact and benefit of the BIER data-plane to the overall Internet architecture. The WG did not produce this RFC, but the goals of that milestone have nevertheless been reached; i.e., the industry has demonstrated interest in deploying BIER and the trade-offs are now well understood. Therefore, BIER is proceeding with work on the Standards Track.
The focus of the BIER-WG is on deployment: transition, partial deployments, applicability and management.
First and primarily, the BIER-WG will complete its work on:
Transition Mechanisms and Partial Deployments: The WG will describe how BIER can be introduced in existing multicast networks to shift multicast delivery, either end-to-end or in part of a network, from mechanisms such as PIM, ng-MVPN, etc. BIER operation in networks where not all routers are BIER capable or have other BIER support constraints should be addressed. How to handle routers supporting BIER with different BitStringLengths and encapsulations should be addressed. Each new mechanism should include an applicability statement that clearly describes its utility and distinctions from already standardized mechanisms.
Applicability Statements: The WG will continue to work on documents describing how BIER can be applied, as has been done for MVPN in RFC8556. A document describing applicability to EVPN should be published.
Use Case: The WG will produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases.
Manageability and OAM: The WG will describe how OAM will work in a BIER domain and what simplifications BIER offers for managing the multicast traffic. A strong preference will be given to extensions to existing protocols.
Management models: The WG will work on YANG models to manage BIER.
Link-State Routing and BGP extensions: The BIER-WG has already defined the basic information needed to set up the BIER forwarding tables via advertisements in OSPFv2 and ISIS; the extensions to OSPFv3 will be specified. Additional extensions may be needed - for example, to support constraining the topology on which a particular BIER sub-domain operates. Any necessary extensions to the IGP will be specified by the WG as Standards Track, in cooperation with the LSR WG. The BIER-WG shall also specify the extensions to support BIER for BGP when used as an IGP (see RFC7938) and to provide BIER-specific information in BGP-LS, incooperation with IDR.
The BIER-WG is additionally chartered to start Standards Track work on:
7) BIER in IPv6 : A mechanism to use BIER natively in IPv6 may be standardized if coordinated with the 6MAN WG and with understood applicability.
8) Forwarding Plane Mechanisms for BIER Traffic Engineering: definition of how the new BIER forwarding plane structures (e.g. BIFT) can be used to support engineered multicast trees. No control-plane work will be done in BIER-WG.
The BIER-WG will serve as a forum to discuss how BIER can be applied. The BIER-WG will coordinate and collaborate with other WGs as needed. Specific
expected interactions include:
RFC8279 -- BIER Architecture
RFC8296 -- BIER MPLS and non-MPLS encapsulation
BIER Problem Statement -- BIER Problem Statement for reference
RFC8401 -- BIER ISIS extensions
RFC8444 -- BIER OSPF extensions
RFC8556 -- BIER MVPN
RFC9262 -- BIER TE Architecture
RFC9272 -- BIER BAR IPA
We're considering an interop event as part of the IETF118 hackathon. Arrcus, Cisco, Juniper, Nokia, and ZTE have shown interest (this is not the final list - please add/remove to truly reflect your organization's intent).
It is expected to have mixed virtual and physical BFRs connected by a switch. The exact environment is to be figured out.
The following functionalities are expected to be tested:
This page will be updated with more details as we figure things out.
Require a deployment experience draft describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms. Ideally, this should also contain an analysis of the impact and benefit of the new BIER data-plane to the overall Internet architecture.
The content of this page was last updated on 2016-04-18. It was migrated from the old Trac wiki on 2023-01-12.