Hi Brian, Thanks a lot for your review and comments. I've submitted revision -17 to address comments from you, Eric, and Roman. https://author-tools.ietf.org/iddiff?url2=draft-ietf-bier-idr-extensions-17 Please see zzh> below (there were no changes for two comments). Juniper Business Use Only -----Original Message----- From: Brian Haberman via Datatracker <noreply@xxxxxxxx> Sent: Thursday, December 12, 2024 1:14 PM To: int-dir@xxxxxxxx Cc: bier@xxxxxxxx; draft-ietf-bier-idr-extensions.all@xxxxxxxx; last-call@xxxxxxxx Subject: Intdir telechat review of draft-ietf-bier-idr-extensions-16 [External Email. Be cautious of content] Reviewer: Brian Haberman Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-bier-idr-extensions-16.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!GOWUyPtsLgLgJvMNu-5RoaBNvdiEQDP02bnEEx6kDRuntyVnQ1J9Nl9TOVFF64Xh-Fv5gQlC0tZb2mg$ <https://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!GOWUyPtsLgLgJvMNu-5RoaBNvdiEQDP02bnEEx6kDRuntyVnQ1J9Nl9TOVFF64Xh-Fv5gQlC0tZb2mg$ >. This is a well-written document and I only have a few minor issues to mention: 1. Section 3 - The guidance provided that unknown or unsupported TLVs are to be ignored and propagated is appropriate, but implementations that do not implement this spec will not know that unless that behavior is standard for BGP. If it is standard, it would be useful to reference the RFC where that guidance is first documented. Zzh> The path attribute itself is transitive so if an implementation does not support BIER at all then the entire BIER path attribute is ignored and propagated because of the transitive nature. If an implementation supports BIER per this specification, then the guidance/requirement for the handling of future/unknown TLVs in the BIER path attributes is defined in this document: ignore and propagate. 2. Section 3 - Should "a BFR needs to include one BIER TLV for every Sub-domain that the prefix belongs to" be re-worded to use MUST? Zzh> Yes. Fixed. 3. Should there be mention of error checks to ensure that the TLVs do not cause the Update message to exceed the maximum allowable size (4K or 64K depending upon support for extended messages)? Zzh> I think that's taken for granted - for any BGP extensions. I thought of adding "The BIER attribute MUST NOT cause the BGP update message to exceed the maximum allowable size", but it should be that all things together (not just BIER) should not exceed the maximum allowable size: +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ Zzh> But that becomes self-evident. I can add it if you really want it to be added😊 4. Section 4 - I was expecting some mention of procedures in this section that describes how the BIER information is prevented from leaking out of an AS. Zzh> That is documented in section 7. 5. What harm is caused if BIER information is propagated outside of an administrative domain? Those should be listed in the Security Considerations section. Zzh> Because the security considerations section refers to the operational considerations section, I added/adjusted some text in the operational section. Zzh> Thanks! Zzh> Jeffrey -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
