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
Technical Summary:
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 Quality
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.
Personnel
Document Shepherd: Tony Przygienda (prz@juniper.net)
Responsible Area Director: Alia Atlas (akatlas@gmail.com)
3) As WG chair I am intrinsically familiar with the document and its
progression over time. Review ensured a. architectural b. technical
consistency c. readability (see nits section) d. references
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
1.
"
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.
2.
"
which the packet has been assigned, a Set-Id (SI),
a BitString, and a BitStringLength (BSL) Together these
"
Dot missing
3.
"
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
OAM packet.
"
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
value.
"
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