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