(1) Experimental, as per charter. The document title page header indicates experimental.
This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast data packets through a "multicast domain". However, it does not require the use of a protocol for explicitly building multicast distribution trees, and it does not require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER).
Working Group Summary:
Working group showed solid consensus for this document. The relevant point of contention was only around the charter?s current direction for this work to be submitted on the Experimental track. Feedback from the AD indicated that there is a path to transition from Experimental to Standards track if there in consensus to do so in the future. When a multicast data packet enters the 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 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. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.
The vendors are being quite tight lipped about current implementations. Operator feedback indicates there are at least two implementations currently, with others in the works. There are currently five vendors collaborating on the work in the IETF. There is no MIB doctor or other expert review outside of the active working group members
Document Shepherd: Greg Shepherd email@example.com
Area Director: Alia Atlas firstname.lastname@example.org
(3) This document reached consensus in Working Group Last Call to progress to the IESG.
(4) No concerns
(5) This work is viewed as being considerably valuable. It does however describe a new forwarding plane, and therefore has drawn the necessary attention to vet the proposed solution as part of the Internet Architecture.
(6) No concerns
(7) All authors have confirmed IPR disclosures.
(8) All authors confirmed on the email list that any relevant IPR disclosures have been filed in reference to this docmument.
(9) The WG as a whole understands and agrees.
(10) No appeals.
(11) No nits.
(12) No formal review required.
(13) All references correctly documented.
(14) All normative references are existing RFCs.
(15) No downward normative references.
(16) This document does not change the status of any existing RFCs
(17) This document contains no actions for IANA.
(18) This document contains no actions for IANA.
(19) XML nit tool returns with no errors.