1) The RFC is following Experimental track. According to the current charter https://datatracker.ietf.org/doc/charter-ietf-bier/, BIER documents are experimental until charter conditions are met to adjust them to Standards Track.
2) Document Announcement
BIER represents a novel forwarding paradigm resulting in a
replication-capable network underlay. The according header contains,
amongst other information, 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 header. The details of the encapsulation depend on
the type of network used to realize the multicast domain. This document
specifies a BIER encapsulation that can be used in an MPLS network,
or with slight differences, in a non-MPLS network as well.
Working Group Summary
This document was processed by the BIER WG and underwent
extensive WG and MPLS WG last call review. Several other
proposals for non-MPLS encapsulation have been extended but
expired after this document covered the space in a more
uniform way. The document underwent
a well-attended face to face interim WG meeting.
Ultimate WG consensus was solid and the document has
been supported by representatives of all major vendors, multiple large
customers and a large custom silicon vendor.
Document underwent extensive number of revisions and
solid amount of convergence and discussion over a
period of three years. One major vendor confirmed
implementation. At least two other, major vendors
seem to be in the process without explicit confirmation.
Document Shepherd: Tony Przygienda (email@example.com)
Responsible Area Director: Alia Atlas (firstname.lastname@example.org)
3) As WG chair I am intrinsically familiar with the document and its progression over time. Review ensured
b. technical consistency
c. readability (see nits section)
4) I have no concerns about the depth or breadth of reviews performed on this document. I consider this document extremely well vetted
5) MPLS WG was involved in the LC which covers IMO all angles necessary. Security and other aspects has been reviewed in the scope of the BIER architecture document
6) Only concern discernible is one workgroup participant being consistently unhappy with the wide consensus on this document. A somewhat competing document he originally co-authored never gathered serious backing or addressed serious defects it contained. Ultimately, the said workgroup member did not participate in detailed discussions further or joined the interim meeting on this very issue/draft. At this point in time, the concerns seem to have been addressed by a recently published draft https://tools.ietf.org/html/draft-wijnandsxu-bier-non-mpls-bift-encoding that the participant co-authored.
7) All authors confirmed on the mailing list that all IPR has been disclosed to the best of their knowledge.
8) IPR has been filed by Cisco in two instances and disclosed. No further discussion.
9) My reading is that we have a strong consensus of the workgroup. The author list is long, discussions on the list happened, document was in long LC, 2 days interim held.
10) I wouldn’t call the dissent of the single person mentioned in 6. extreme but it was rather persistent. Technical arguments have been made and proposal extended, found wanting (it was extending control plane concepts into forwarding plane which would have led to very poor performance and scale in FIBs without providing any new or relevant functionality) and the drafts expired. As mentioned in 6. a new, viable draft has been published as https://tools.ietf.org/html/draft-wijnandsxu-bier-non-mpls-bift-encoding and it seems to address the concerns, solution space within the framework of this draft.
11) Nits were given to authors already and are being addressed in upcoming final version. For historical accuracy attached below
that architecture provides optimal forwarding of multicast
data packets through a "multicast domain".
remove optimal, optimal is only defined if a cost function is provided (and can differ depending on application) which is lacking in the document/architecture.
which the packet has been assigned, a Set-Id (SI),
a BitString, and a BitStringLength (BSL) Together these
Following the BIER header is the "payload". The payload may be an
IPv4 packet, an IPv6 packet, an ethernet frame, an MPLS packet, or an
Make the list open, there may be more. You can refer to bier-ping for value of 5 e.g.
4. A more serious one
This 20-bit field specifies an "entropy" value that can be used
for load balancing purposes. The BIER forwarding process may do
equal cost load balancing, but the load balancing procedure MUST
choose the same path for any two packets have the same entropy
Does that apply even if we do non-deterministic ECMP. I don't think so, then it's 'same entropy _and_ same set of receivers'
5. Another interesting one
Should a received all-0's bitmask be said to "SHOULD discard and log error" or we let it ride?
6. Update draft versions in references
7. Refer in security section to the architecture draft to cover things like attack vectors?
12) No formal review criteria found, normative language checked
13) Normative and informative checked. Looks OK
14) Normative references are RFCs. BIER architecture is only draft which passed all RFC milestones, pretty much ready for publication
15) No downward references that I found
16) No other RFCs are being updated or obsoleted by this RFC
17) IANA section looks clean. IANA next protocol value registry has been requested but could not be created using early allocation process. Other values have been checked and have been communicated as not needing IANA allocation.
18)"BIER Next Protocol Identifiers" registry will most likely require future expert review
19) No formal sections needing tool checks. BIER header section has been very extensively reviewed by many experts and rearranged, extended based on comments