Bit Indexed Explicit Replication
charter-ietf-bier-00-00

BIER charter:

WG Chairs:
Greg Shepherd <gjshep@gmail.com>
Tony Przygienda <antoni.przygienda@ericsson.com>

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
header.

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
implementations.

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
mechanisms.

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
considerations.

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
information.

Milestones:

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
etc.