[Bier] Re: Genart last call review of draft-ietf-bier-idr-extensions-12

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Behcet,

Thanks for your review and comments. I have posted the -13 revision to address them.

Please see zzh> below for some clarifications.


Juniper Business Use Only
-----Original Message-----
From: Behcet Sarikaya via Datatracker <[e-mail]>
Sent: Wednesday, October 2, 2024 1:10 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Genart last call review of draft-ietf-bier-idr-extensions-12

[External Email. Be cautious of content]


Reviewer: Behcet Sarikaya
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<https://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!NEt6yMaO-gk!CgASV5ezXUNVWAIcPScISj_9M9mrzOL4DJQj9p4W9uWSCIaag2HDY49NYNgzROHCwWyPOw1L53mngJ0$ >.

Document: draft-ietf-bier-idr-extensions-??
Reviewer: Behcet Sarikaya
Review Date: 2024-10-02
IETF LC End Date: 2024-10-03
IESG Telechat date: Not scheduled for a telechat

Summary:The document presents BGP extensions for advertising the BIER information and methods for calculating BIER states based on the advertisement.
Basically it interfaces BIER with BGP for realizing the multicast delivery.

Major issues:As security reviewer pointed out, Sec. 1 claims the BIER attributes leaking out of BIER domain avoidance is not realized. It has excessive number of editorial issues. It has 6 authors.

Zzh> As the security reviewer pointed out, the operation consideration section does talk about leak prevention. As I responded there, I added a reference to Sec. 1.
Zzh> The six-author justification is provided in the shepherd write-up: "There are six authors and all have contributed to the document.The sixth co-author Zhaohui Zhang  is the main editor of version 8 and version 9. He make a huge effort to improve the draft.".
Zzh> Sorry for the editorial issues especially the silly typos. Sometimes I forget to run revisions through the spell/grammar checker. I hope I have now addressed all of them.

Minor issues:

Nits/editorial comments:
to coney -> to convey

zzh> Fixed.

the original draft name has idr extensions not BGP extensions. Of course draft name is very difficult to change after so many revisions.

Zzh> Right. The draft name does not really matter 😊

Section 2 on terminology does not contain all the acronyms used.
All acronyms should be expanded in first use.

Zzh> I added/expanded AFI/SAFI/NLRI/BIFT/LSP/AS. Please let me know if I missed anything else.

Some TLV figures have a figure number some don't, why?

Zzh> No good reason 😊 Apparently some use "figure" and some use "artwork". I have fixed them.

Sec. 5 second par. sub-TLV at all, The entry's BFR Neighbor -> sub-TLV at all, the entry's BFR Neighbor

Zzh> Fixed.

Sec.5 states that BIER traffic is sent to the BFR-NBR either natively (BIER header
   directly follows a layer 2 header) if the BFR-NBR is directly
   connected,

I think this is very important to emphasize that BIER supports/ realizes native multicast deliver as opposed to tunneling so the document should single out the cases of tunneling everywhere in the document.

Zzh> The tunneling is only mentioned in these three paragraphs for the applicable scenarios, and I believe it is appropriate:

   BIER traffic is sent to the BFR-NBR either natively (BIER header
   directly follows a layer 2 header) if the BFR-NBR is directly
   connected, or via a tunnel otherwise.  Notice that, if a non-BFR BGP
   speaker re-advertises a BIER prefix (in this case it can not update
   the BIER attribute since it is not capable), or if a BFR BGP speaker
   re-advertises a BIER prefix without updating the BIER Nexthop sub-
   TLV, the BFR receiving the prefix will tunnel BIER traffic - the BGP
   speaker re-advertising the BIER prefix will not see the BIER traffic
   for the BIER prefix.

   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 LSP or IP/GRE, as
   long as the tunnel header can indicate that the payload is BIER.

   ...

   When BFR1 receives the routes, it calculates the BIFT entries, using
   BFR2's address encoded in the BIER Nexthop sub-TLV as the nexthop.
   Because BFR2 is not directly connected, a tunnel must be used.

Sec.6 BFRer1 -> BFER1

Zzh> Fixed.

Zzh> Thanks!
Zzh> Jeffrey