Bit Indexed Explicit Replication

The information below is for an older proposed charter
Document Proposed charter Bit Indexed Explicit Replication WG (bier) Snapshot
Title Bit Indexed Explicit Replication
Last updated 2015-02-09
State Not currently under review
WG State Active
IESG Responsible AD Alvaro Retana
Charter Edit AD Alia Atlas
Send notices to (None)


BIER charter:

WG Chairs:
  Greg Shepherd  <>
  Tony Przygienda <>

Existing multicast forwarding has depended upon identification of the
multicast group in the packet and control plane signaling to cause the
necessary forwarding state to be set up.  This tight coupling of
multicast groups with control plane information requires that each
router maintain per multicast group flow state and participate in the
associated control plane signaling when that router is on the path
from the sender to one or more of the recipients.

BIER defines a new multipoint forwarding mechanism, which is known as
Bit Index Explicit Replication.  When a multicast data packet enters
the BIER domain, the ingress router determines the set of egress
routers to which the packet needs to be sent.  The ingress router then
encapsulates the packet in a BIER header.  The BIER header contains a
subset of a bitstring in which each bit represents exactly one egress
router in the domain; to forward the packet to a given set of egress
routers, the bits corresponding to those routers are set in the BIER

Due to the particular sensitivity of adding new significant
functionality into the data-plane, the BIER work will progress as
Experimental.  BIER is chartered to do experimental work on this new
multicast forwarding mechanism as follows:

   1) BIER architecture: The WG will publish an architecture, based
   upon draft-wijnands-bier-architecture-04.  It will include the
   normative algorithm for how BIER packet forwarding is done.  It
   will specify the information that is required by a BIER header to
   support BIER forwarding.

   2) BIER encapsulation: The WG will publish an experimental RFC
   defining an MPLS-based encapsulation based upon
   draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need
   to have a high-quality and stable RFC for a new data-plane
   encapsulation, the MPLS-based encapsulation draft may not progress
   to IETF Last Call until there are multiple hardware-based

   Due to the long lead time in producing new hardware-based
   implementations and as a secondary focus, the WG may also work on
   one non-MPLS data-plane encapsulation.  This draft may also not
   progress to IETF Last Call until there are multiple hardware-based
   implementations.  This draft must focus on and include the
   following details:

       a) What is the applicability of the encapsulation and why is
       this encapsulation required?

       b) Does this proposed encapsulation require any changes to 
       the MPLS-based encapsulation?

       c) What design choices have been made for the encapsulation
       type and the included fields.

       d) The proposed encapsulation with considerations given to at
       least OAM, Class of Service, security, fragmentation, TTL.

   3) Transition Mechanisms: The WG will describe how BIER can be
   partially deployed and still provide useful functionality.  A
   minimum of the necessary mechanisms to support incremental
   deployment and/or managing different BIER mask-length compatibility
   may be defined.  Each such mechanism must include an applicability
   statement to differentiate its necessity from other proposed

   4) Applicability Statements: The WG will work on a document
   describing how BIER can be applied to multicast L3VPN and to EVPN.
   This draft will describe what mechanism is used to communicate the
   group membership between the ingress router and the egress routers,
   what scalability considerations may arise, and any deployment

   5) Use Case: The WG may produce one use-case document that clearly
   articulates the potential benefits of BIER for different use-cases.
   This would be based upon draft-kumar-bier-use-cases-01.

   6) 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.

   7) IGP extensions: BIER uses the IGP topology for multipoint
   forwarding.  BIER requires that a mapping from bit position in the
   bitmap to router be flooded across the IGP so that routers can
   build the BIER forwarding table.  The WG will specify, in
   cooperation with the ISIS and OSPF working groups, the new
   advertisements needed to support BIER.

   8) Deployment Experience: Once there is deployment experience, the
   WG will produce a document describing the benefits, problems, and
   trade-offs for using BIER instead of traditional multicast
   forwarding mechanisms.  This should also contain an articulate
   analysis of the impact and benefit of the new BIER data-plane to
   the overall Internet architecture.  This document may be used to
   evaluate whether and when BIER may produce Standards Track RFCs as
   well as Experimental.  The WG will be responsible for producing

The BIER working group will coordinate with several different working
groups and must ensure that there is consensus in the relevant other
working groups during working group last call on the relevant drafts.
BIER will coordinate with MPLS on the MPLS-based encapsulation and
associated MPLS-based OAM mechanisms.  BIER will coordinate with ISIS
and OSPF on extensions to flood BIER-related information.  BIER will
coordinate with BESS and IDR on the applicability of existing
BGP-based mechanisms for providing multicast group membership


IETF Last Call on BIER use-cases
IETF Last Call on BIER Architecture
IETF Last Call on MPLS-based encapsulation
IETF Last Call on OSPF extensions for BIER
IETF Last Call on ISIS extensions for BIER
IETF Last Call on BIER Applicability for MVPN and EVPN
IETF Last Call on BIER-related OAM