Hi Tim, Thanks for your review and comments. I have posted the -14 revision to address them. Please see zzh> below. Juniper Business Use Only -----Original Message----- From: Tim Chown via Datatracker <noreply@xxxxxxxx> Sent: Thursday, October 3, 2024 6:56 AM To: ops-dir@xxxxxxxx Cc: bier@xxxxxxxx; draft-ietf-bier-idr-extensions.all@xxxxxxxx; last-call@xxxxxxxx Subject: Opsdir last call review of draft-ietf-bier-idr-extensions-12 [External Email. Be cautious of content] Reviewer: Tim Chown Review result: Has Nits 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. Zzh> Added. 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. Zzh> The sec section does mention the following 😊 This document introduces no new security considerations beyond those already discussed in [RFC4271] and [RFC8279] and the operational <======= considerations (Section 7) of this document. 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? Zzh> There are only 20 bits to encode the *starting* label/BIFTid. Since it is the starting one in the range, the (value + Max SI) could be more than what a 20-bit number can represent. In that case, the sub-TLV must be ignored. Nits: * Section 2 could include other terminology such as BFR-id, BIFT and BIFT-id. Zzh> Added. * 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 Zzh> Added. * 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. Zzh> It's indeed in its own paragraph? * Tunnelling is mentioned in Section 5, perhaps this possibility should also be stated in the introduction? I initially assumed transmission would be native. Zzh> Added. * In the example in Section 6, it would be useful to clarify how the tunnelling is configured. Zzh> The end of section 5 has the following: How the tunnel is set up and chosen is outside the scope of this document. It can be any kind of tunnel, e.g., MPLS Label Switched Path or IP/GRE, as long as the tunnel header can indicate that the payload is BIER. Zzh> Thanks a lot! Zzh> Jeffrey Best wishes, Tim -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
