Skip to main content

Telechat Review of draft-ietf-bier-idr-extensions-16
review-ietf-bier-idr-extensions-16-intdir-telechat-haberman-2024-12-12-00

Request Review of draft-ietf-bier-idr-extensions
Requested revision No specific revision (document currently at 19)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2024-12-14
Requested 2024-12-05
Requested by Éric Vyncke
Authors Xiaohu Xu , Mach Chen , Keyur Patel , IJsbrand Wijnands , Tony Przygienda , Zhaohui (Jeffrey) Zhang
I-D last updated 2025-06-13 (Latest revision 2024-12-19)
Completed reviews Rtgdir IETF Last Call review of -11 by Ketan Talaulikar (diff)
Secdir IETF Last Call review of -12 by Brian Weis (diff)
Opsdir IETF Last Call review of -12 by Tim Chown (diff)
Genart IETF Last Call review of -15 by Behcet Sarikaya (diff)
Intdir Telechat review of -16 by Brian Haberman (diff)
Comments
Thanks for a review done from the multicast angle.
-éric
Assignment Reviewer Brian Haberman
State Completed
Request Telechat review on draft-ietf-bier-idr-extensions by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/1VeH_wytT9-D51PDWAGLYGFm9Xo
Reviewed revision 16 (document currently at 19)
Result Ready w/nits
Completed 2024-12-12
review-ietf-bier-idr-extensions-16-intdir-telechat-haberman-2024-12-12-00
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://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

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.

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?

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)?

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.

5. What harm is caused if BIER information is propagated outside of an
administrative domain? Those should be listed in the Security Considerations
section.