Skip to main content

Shepherd writeup
draft-ietf-bier-architecture

(1) Experimental, as per charter. The document title page header indicates
experimental. (2) Technical Summary: 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. Document Quality: 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 Personnel:
Document Shepherd: Greg Shepherd gjshep@gmail.com Area Director: Alia Atlas
akatlas@gmail.com (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.

Back