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 2018-01-23
State Draft Charter Rechartering
WG State Active
IESG Responsible AD Alvaro Retana
Charter Edit AD Alia Atlas
Send notices to (None)


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 and to 
update or do a Status Change for those RFCs previously published as 
Experimental (RFC 8279, RFC 8296, etc.).
First and primarily, the BIER-WG will complete its work on:
  1) 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. 
     Operation of BIER in non-congruent topologies, i.e. 
     topologies where not all routers are BIER capable can 
     also be addressed. In addition to tunneling solutions, other 
     approaches to make BIER deployable in such environments 
     can be worked on. Each such mechanism must include an 
     applicability statement to differentiate its necessity from 
     other proposed mechanisms.
  2) Applicability Statements: The WG will describe 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 
     considerations. The WG will work on additional applicability 
     statements, as needed, describing how BIER can be applied.
  3) Use Case: The WG may produce one use-case document that clearly 
     articulates the potential benefits of BIER for different use-cases.
  4) 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. 
  5) Management models: The WG may work on YANG models and, if needed, MIB 
     modules to support common manageability.
  6) IGP extensions. When a BIER domain falls within a "link state IGP" 
     network, the information needed to set up the BIER forwarding tables 
     (e.g., the mapping between a given bit position and a given egress 
     router) may be carried in the link state advertisements of the IGP. 
     The link state advertisements may also carry other information related 
     to forwarding (e.g., the IGP may support multiple topologies, in which 
     case it may be necessary to advertise which topologies are to be used 
     for BIER forwarding). Any necessary extensions to the IGP will be 
     specified by the WG as Standards Track, in cooperation with the LSR WG.
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.  Such functionality may focus on assuming software or 
     slow-path support first.
  8) BIER Traffic Engineering:  An architecture for BIER-TE is defined 
     in draft-ietf-bier-te-arch; associated fundamental technology is included.
  9) Extensions to support BIER in multi-area IGP Deployments
The BIER-WG is chartered to investigate the following topics. The adoption 
of any Standards Track drafts will require a milestone approved by the 
responsible Area Director.
  10) Novel uses of the BIER bitmap: There are a variety of proposals for 
      additional algorithms and other uses of the BIER bitmap and 
      encapsulation beyond BIER and BIER-TE.  
  11) BIER between Autonomous Domains:   With understood applicability, 
      these scenarios may be investigated.  
  12) Use of BIER in Controller-based Architectures:  How might controllers 
      be used to provide calculated BIRTs and/or BIFTs tables to BFRs?
  13) Applicability of BIER to Applications: The WG may advise on the 
      applicability of BIER to various applications. 
The BIER-WG will coordinate with several different working groups and 
must include the relevant other working groups during working group 
last call on the relevant drafts. BIER-WG will coordinate with MPLS-WG 
on the associated MPLS-based OAM mechanisms. BIER-WG will coordinate with
LSR-WG on extensions to flood BIER-related information. BIER-WG will 
advise BABEL-WG on Babel extensions to support BIER. BIER-WG will 
coordinate with BESS-WG and IDR-WG on the applicability of existing 
BGP-based mechanisms for providing multicast group membership information. 
BIER-WG will coordinate with PIM-WG on the applicability of and extensions 
to PIM, IGMP, and MLD to support BIER operations and transition; BIER-WG 
will work directly on the applicability statements, as needed.