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