Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks
RFC 8296

Received changes through RFC Editor sync (created alias RFC 8296, changed title to 'Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks', changed abstract to 'Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol.  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 bit string 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.  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.', changed pages to 24, changed standardization level to Experimental, changed state to RFC, added RFC published event at 2018-01-12, changed IESG state to RFC Published)

[Ballot comment]
The definition of BSL indicates:

      Note: When parsing the BIER header, a BFR MUST infer the length of
      the BitString from the BIFT-id, and MUST NOT infer it from the
      value of this field.

It then goes on to say:

      The value of this field MUST NOT be set to any value other than
      those listed above.  A received packet containing another value in
      this field SHOULD be discarded, and an error logged.

The expectation that the router is auditing the value of this field raises the question of whether the router should check if the length indicated by the BFR field is different than the BFR that corresponds to this packet's BIFT-id.

My suggestion would be to make this consistent: either routers always ignore the value of this field (even if it is out of range), or routers verify not just that the value is valid, but that it is in fact accurate.

----------------------------------------------------------------------

I don't see any information in the ballot or the shepherd's write-up discussing the rationale for having more than five authors on this document. Has this been discussed with the authors, contributors, and working group already?

[Ballot discuss]
I share the concerns of the SecDir reviewer and would like to see more text in the Security Considerations that reflect the inherent trust model and also the lack of integrity protection for the BIER encapsulation.  Having these items detailed explicitly is an important consideration for implementers.  I do realize that this is the current state with MPLS, but it bears repeating for a new encapsulation.

https://mailarchive.ietf.org/arch/msg/secdir/w8qqQtzlEi00uToUGT0N8XVuHkI

Thank you.

[Ballot comment]
- Please add some text describing the nature of the experiment, even if that is simply "to get more implementation and deployment experience".

- 2.1.2, "Ver": " The value 0xF is reserved for experimental use; that value MUST
      NOT be assigned by any future IETF document or by IANA."

Isn't the entire document experimental? It seems odd to define an experimental version code.

[Ballot comment]
[ Edit: Thanks for addressing my DISCUSS - I think that the document is now even better ]


I like the document (with Mirja's MTU issue resolution) - I went through trying to find nit's to improve it, but came up dry!

-- Original discuss for posterity ---
I believe that there needs to be better guidance of what to do when the TTL expires (and want to thank Al (OpsDir) for noticing this):
"Of course, if the incoming TTL is 1, the packet MUST be treated as
      a packet whose TTL has been exceeded.  The packet MUST NOT be
      forwarded, but it MAY be passed to other layers for processing
      (e.g., to cause an ICMP message to be generated, and/or to invoke
      BIER-specific traceroute procedures, and/or to invoke other OAM
      procedures.)"

I have read the response to the OpsDir review (https://www.ietf.org/mail-archive/web/ops-dir/current/msg02897.html) -- I fully agree that mandating a response to every packet would be bad, but I think that "it MAY be passed to other layers for processing" is too weak. I think SHOULD would be fine, or, even better, something about "SHOULD, with optional implementation specific rate-limiting" or something. The current text makes it sound like it's perfectly fine to just not bother implementing any sort of reporting / response handing after dropping the packet.
I think that this should be an easy fix and not hold up the document (much or at all)

[Ballot discuss]
I believe that there needs to be better guidance of what to do when the TTL expires (and want to thank Al (OpsDir) for noticing this):
"Of course, if the incoming TTL is 1, the packet MUST be treated as
      a packet whose TTL has been exceeded.  The packet MUST NOT be
      forwarded, but it MAY be passed to other layers for processing
      (e.g., to cause an ICMP message to be generated, and/or to invoke
      BIER-specific traceroute procedures, and/or to invoke other OAM
      procedures.)"

I have read the response to the OpsDir review (https://www.ietf.org/mail-archive/web/ops-dir/current/msg02897.html) -- I fully agree that mandating a response to every packet would be bad, but I think that "it MAY be passed to other layers for processing" is too weak. I think SHOULD would be fine, or, even better, something about "SHOULD, with optional implementation specific rate-limiting" or something. The current text makes it sound like it's perfectly fine to just not bother implementing any sort of reporting / response handing after dropping the packet.
I think that this should be an easy fix and not hold up the document (much or at all)

[Ballot comment]
I like the document (with Mirja's MTU issue resolution) - I went through trying to find nit's to improve it, but came up dry!

[Ballot comment]
Just a couple of minor comments and nits:

- Shouldn’t the example in 2.1.1.1 result in 16 potential labels, and not just 12?  Maybe I'm just missing something obvious...

- From 2.1.1.2: “The BFR MUST perform the MPLS TTL processing correctly.”  Sure, but what does correctly mean?  If the TTL field is “usual MPLS "Time to Live" field ([RFC3032])”, then I think that it is redundant (and not necessary) to repeat the processing here — just the exceptions.  Are there any?

- From 2.1.2: “OAM:…The use of these bits in other than the default manner is OPTIONAL.  Specification of the non-default use or uses of these bits is outside the scope of this document.”  Using Normative language without an actual specification (because it is out of scope) just doesn’t fit: s/OPTIONAL/optional

- Nit: Please include the explanation of the fields (in 2.1.1.2/2.2.1.2) in the same order as the appear on the Header.

[Ballot discuss]
My understanding is that this document specifies a new encapsulation. As such it should also discuss path MTU discovery and fragmentation. Maybe a pointer to section 3 of rfc3032 is sufficient.

[Ballot comment]
Nit:
Given that the BSL can only ever have 7 values, I'm wondering why 4 instead of 3 bits are used, but that's not important...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-bier-mpls-encapsulation-09. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created called the BIER Next Protocol Identifiers registry. The registration policy for this new registry is "Standards Action" as defined in [ RFC 8126 ].

There are initial registrations in this new registry.

Values in this registry must come from the range 0-63.

Value: 0
Description: Reserved
Reference: [ RFC-to-be ]

Value: 1
Description: MPLS packet with downstream-assigned label at top of stack
Reference: [ RFC-to-be ]

Value: 2
Description: MPLS packet with upstream-assigned label at top of stack
Reference: [ RFC-to-be ]

Value: 3
Description: Ethernet frame
Reference: [ RFC-to-be ]

Value: 4
Description: IPv4 packet
Reference [ RFC-to-be ]

Value: 5
Description: OAM packet
Reference: [ id: draft-ietf-bier-ping-02.txt ]

Value: 6
Description IPv6 packet
Reference: [ RFC-to-be ]

Value: 7-62
Description: Unassigned
Reference:

Value:: 63
Description: Reserved
Reference: [ RFC-to-be ]

IANA QUESTION -> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-16):

From: The IESG
To: IETF-Announce
CC: draft-ietf-bier-mpls-encapsulation@ietf.org, bier@ietf.org, akatlas@gmail.com, Tony Przygienda , tonysietf@gmail.com, bier-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS Networks) to Experimental RFC


The IESG has received a request from the Bit Indexed Explicit Replication WG
(bier) to consider the following document: - 'Encapsulation for Bit Index
Explicit Replication in MPLS and non-MPLS
  Networks'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Bit Index Explicit Replication (BIER) is an architecture that
  provides optimal multicast forwarding through a "multicast domain",
  without requiring intermediate routers to maintain any per-flow state
  or to engage in an explicit tree-building protocol.  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.  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bier-mpls-encapsulation/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bier-mpls-encapsulation/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2448/
  https://datatracker.ietf.org/ipr/2985/

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

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 I have is that one workgroup participant seems to be consistently unhappy with the wide consensus on this document. However, the document he 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.
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 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. After that, technical arguments were not advanced anymore really but instead multiple repetitions of the previous proposal occurred on the list.
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

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 I have is that one workgroup participant seems to be consistently unhappy with the wide consensus on this document. However, the document he 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.
7)      In process
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 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. After that, technical arguments were not advanced anymore really but instead multiple repetitions of the previous proposal occurred on the list.
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

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 I have is that one workgroup participant seems to be consistently unhappy with the wide consensus on this document. However, the document he 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.
7)      In process
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 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. After that, technical arguments were not advanced anymore really but instead multiple repetitions of the previous proposal occurred on the list.
11)  Nits (given to authors already)

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

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 co-authored by 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 I have is that one workgroup participant seems to be consistently unhappy with the wide consensus on this document. However, the document he 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.
7)      In process
8)      IPR has been filed by Cisco in two instances and disclosed. No further discussion.
9)      Per 6. My reading is that we have a strong consensus of the workgroup with one dissenting voice that has been heard and acknowledged extensively. 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 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. After that, technical arguments were not advanced anymore really but instead multiple repetitions of the previous proposal occurred on the list.
11)  Nits (given to authors already)

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

Request for posting confirmation emailed to previous authors: Sam Aldrin , Andrew Dolganow , IJsbrand Wijnands , Eric Rosen , Israel Meilik , Jeff Tantsura , bier-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Andrew Dolganow" , "Israel Meilik" , "Eric Rosen" , "Jeff Tantsura" , "IJsbrand Wijnands" , "Sam Aldrin" , bier-chairs@ietf.org