Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-spring-bfd-12.txt/

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

As this document appears to be approaching working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group comments.

For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir

Document: ddraft-ietf-idr-rt-derived-community-08.txt
Reviewer: Joel Halpern
Review Date: 20-April-2026
Intended Status: Standards track

Summary:
I have A concern about this document that I think should be resolved before it is submitted to the IESG.

Comments:
   The document clearly describes the value in having a BGP extended community that is distinct from by derived from a VPN route target, and then explains how to build this.

Major Issues: 
    The document says that it specifies the way to derive this association extended community from the base VPN RT.  I believe I found the "specification" buried in a example clause, that is an e.g., in the introduction.  Could similar text please be added as normative specification in the Specification section of the document?

Minor Issues: N/A

Nits:
    In the introduction, it talks about the case where a secondary route target is used to distribute information for the VPN, and therefore a secondary extended community is needed to indicate that the information is for the VPN.  the text then says "EC2 cannot be the same as RT3 ..."  While  the explanation seems to cover why the distinction is useful, it doesn't lead me as a reader to concluded that it is necessary.  On the other hand, I would find the reverse explanation mor persuasive.  That is, there could be several secondary RTs distributing to different subsets of nodes within the VPN, and it would be good to use a single binding extended community value to make clear that all of them are related to the same VPN.  So one would have EC2 and RT3, Rt4, ...