Early Review of draft-ietf-idr-rt-derived-community-08
review-ietf-idr-rt-derived-community-08-rtgdir-early-halpern-2026-04-20-00

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, ...