Last Call Review of draft-ietf-bier-idr-extensions-12
review-ietf-bier-idr-extensions-12-opsdir-lc-chown-2024-10-03-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The draft defines the means by which BIER-specific information can be conveyed
a new BGP BIER path attribute.

The mechanism would appear to have genuine, useful use cases.

Overall the document is well-structured and well-written, and is generally
ready to progress to the IESG for their consideration, but I have a some
comments and some nits to be addressed below.

Major comments:
none

Comments:

1. The document states in the operational considerations section that this
method is only designed for use within a single administrative domain (which
may be multi-AS). This should be stated very clearly in the abstract and early
in the introduction.

2. The potential leakage of BIER-specific information is mentioned i the
introduction and within the operational considerations section, but not in the
security section, where it should be explicitly included.  I'd presume that
forwarding of attributes would be managed in a similar way to other types of
attributes.

3. In Sections 3.1 and 3.2 the text that states behaviour when the 20-bit range
is exceeded is unclear.  Does it mean that if the label is more than 20-bits it
should not be encoded, or that if a label greater than 20 bits is received it
MUST be ignored?  If the latter, and the field length is 20 bits, how does the
receiver know the label length?

Nits:

* Section 2 could include other terminology such as BFR-id, BIFT and BIFT-id.

* Sections 3.1, 3.2 and 3.3 should state that the length field is a 2-octet
field as per the main attribute description

* Overlaps are discussed at the bottom of section 3.2. That should be at the
very least a new paragraph for clarity, or perhaps a new section on the general
issue of overlaps.

* Tunnelling is mentioned in Section 5, perhaps this possibility should also be
stated in the introduction?  I initially assumed transmission would be native.

* In the example in Section 6, it would be useful to clarify how the tunnelling
is configured.

Best wishes,
Tim