Early Review of draft-ietf-idr-node-target-ext-comm-03
review-ietf-idr-node-target-ext-comm-03-opsdir-early-chintha-2026-09-02-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of "Guidelines for Considering Operations and Management in IETF
Specifications" can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-idr-node-target-ext-comm-03
- Reviewer: Venkata Ramanaiah Chintha
- Review Date: 2026-09-02
- Intended Status: Standards Track


--------------------------------------------------------------------------
SUMMARY
--------------------------------------------------------------------------

Has Issues: I have some concerns about this document that I think should be
resolved before publication.

The mechanism is well motivated and the encoding is simple and clear. My
comments are limited to the operations and management dimension; I have not
attempted a full protocol or security analysis.

They reduce to one theme: the document specifies an on-the-wire object and a
local decision rule, but not how an operator provisions the target information,
confirms it took effect, or diagnoses the case where it did not. That matters
more than usual here because the failure mode is silent. A route affected by
this mechanism is received and accepted normally and then simply not installed,
with no withdrawal, no session event, and no error.


--------------------------------------------------------------------------
GENERAL OPERATIONAL COMMENTS / ALIGNMENT WITH RFC 5706bis
--------------------------------------------------------------------------

The operational content of the document is confined to Section 4 (Compatibility
Considerations), which addresses incremental deployment alongside legacy
speakers. There is no Operational Considerations section, and no discussion of
configuration, monitoring, or verification anywhere in the document.

Against the RFC 5706 checklist:

  Deployment
    Partially addressed. Section 4 covers coexistence with legacy speakers. It
    does not describe how the mechanism is managed once deployed.

  Installation and Initial Setup
    Not addressed. No configuration parameters are identified and no defaults
    given. The clearest example is the transitive (0x01) vs. non-transitive
    (0x41) choice, offered in Section 2 with no selection guidance.

  Migration Path
    Partially addressed. Section 4 is the strongest operational content in the
    document, but see Minor Issue 5.

  Requirements on Other Protocols
    Not addressed. The interaction with the FlowSpec validation procedure is
    unspecified; see Minor Issue 4.

  Impact on Network Operation
    Not addressed. See Minor Issue 6 on the cost of large target groups.

  Verifying Correct Operation
    Not addressed. This is my principal concern; see the Major Issue below.


--------------------------------------------------------------------------
MAJOR ISSUES
--------------------------------------------------------------------------

1. The document has no Operational Considerations section, and the mechanism's
   failure mode is not observable.

   draft-ietf-opsawg-rfc5706bis, which this review is conducted against and
   which is currently with the IESG as a proposed BCP, requires new IETF RFCs
   documenting protocols to include an Operational Considerations section.
   This document has none. I would ask the authors to add one, covering at
   minimum the three items below.

   (a) Fault management (RFC 5706 Section 3.3). Today there is no way for an
       operator to answer the first question this feature will ever generate:
       "why did node X not install this route?" A route suppressed by a Node
       Target mismatch is externally indistinguishable from one that was never
       advertised. I would like the document to say what state a speaker
       should expose -- the Node Target communities received, the resulting
       target / non-target determination, and a count of routes suppressed by
       this mechanism -- so that the condition is observable both per-route and
       in aggregate. This is the item I would most like to see addressed.

       I note in passing that the same gap means an injected or misconfigured
       Node Target community that suppressed this information domain-wide
       would produce no operational signal either. I raise this only as a
       consequence of the observability gap; a full threat analysis is outside
       the scope of this review.

   (b) Configuration management (RFC 5706 Section 3.4). Section 3 says a
       "network controller or BGP speaker" originates these communities, which
       means the originator must hold an accurate node-to-BGP-Identifier
       inventory for the administrative domain. The document does not say
       where that inventory comes from or how it is kept current.

       This matters for two reasons. First, Section 3 defines the domain as
       one that "may consists of one or multiple ASes managed by a single
       operator", while RFC 6286 scopes BGP Identifier uniqueness to a single
       AS -- with the useful clarification in its Section 2 that "In case of
       BGP Confederation, the whole confederation is considered as one AS for
       the purpose of supporting the AS-wide Unique BGP Identifier". Across
       genuinely separate ASes under common management, uniqueness is
       therefore not guaranteed by RFC 6286 alone, and the obligation falls to
       the operator. The document should say so.

       Second, BGP Identifiers change in ordinary operational practice --
       hardware replacement, renumbering, a device rebuilt from a template.
       When one changes, the target set silently stops matching for that node,
       with no signal to the originator or the operator. A note that an
       identifier change invalidates existing target lists would close this.

   (c) Verifying correct operation. Related to (a) but distinct: the document
       should say how an operator confirms, after configuring a target set,
       that the intended nodes and only the intended nodes acted on it.


--------------------------------------------------------------------------
MINOR ISSUES
--------------------------------------------------------------------------

1. The receiver rule in Section 3 does not hold when more than one Node Target
   community is present. Section 2 permits "One or more Node Target extended
   communities ... to designate a group of target BGP nodes", but Section 3
   then says:

     "If the target BGP Identifier in any of the Node Target extended
      community does not match with the local BGP Identifier, this node is not
      the target node of Update..."

   For a group {A, B, C} and a local node A, the identifiers B and C do not
   match, so read literally the node concludes it is not a target. This
   contradicts the preceding sentence in the same paragraph. I believe the
   intent is "if none of the Node Target extended communities matches". I
   raise it here because the operational consequence is that different
   implementations may reach different conclusions from the same Update, and
   given the Major Issue above that divergence would be hard to diagnose in a
   multi-vendor network. I would treat this as more than editorial.

2. IANA Considerations -- please confirm the status of the early allocation.
   The IANA "BGP Extended Communities" registry currently shows sub-type 0x09
   assigned to "Node Target Extended Community" in both the Transitive and
   Non-Transitive IPv4-Address-Specific sub-type registries, referencing
   draft-ietf-idr-node-target-ext-comm-01 with a date of 2021-06-11. Per
   RFC 7120, an early allocation is valid for one year and may normally be
   renewed only once, and an expired early allocation is best treated as
   deprecated. Given the elapsed time I would ask the shepherd or the
   responsible AD to confirm the allocation is still valid before the document
   proceeds. Separately, Section 2 still says the sub-type is "TBA" while
   Section 5 states 0x09; these should agree, and Section 5's phrasing ("IANA
   assigns...") should be adjusted to reflect that an early allocation has
   been made rather than reading as a new request.

3. Receiver behaviour beyond "not eligible to be installed" is unspecified.
   Please state whether a non-target route is retained in Adj-RIB-In or
   discarded, whether it is re-advertised, and whether it counts against
   inbound prefix limits. These are operator-visible in show output and
   telemetry, so leaving them open means the same network reports different
   things on different platforms, which compounds the Major Issue above.

4. Interaction with FlowSpec validation is unspecified. FlowSpec is the
   motivating use case in the Introduction, so please state whether the Node
   Target check is applied before or after the RFC 8955 validation procedure.

5. Section 4's mitigation is in tension with the Introduction's rationale. The
   Introduction rejects the approach of configuring "on each router, a
   community and the corresponding policies" because it "relies on manual
   configuration thus is considered error-prone". Section 4 then mitigates
   legacy behaviour by "setting appropriate routing policies on the legacy BGP
   nodes" -- the same manual per-router policy, now required on the nodes
   least likely to be actively maintained. During migration an operator runs
   both. I am not asking for a different mitigation, only that Section 4
   acknowledge this and offer some guidance on staging a rollout, particularly
   for the FlowSpec case where Section 4 notes the impact reaches the
   forwarding plane.

6. The cost of large target groups is not discussed. Each target consumes an
   8-octet extended community and targets are enumerated individually, so a
   large group is a substantial addition to every affected Update, with a
   corresponding generation and churn cost at the originator. A sentence
   acknowledging the practical limit and what an operator should do when the
   target group is large would help.


--------------------------------------------------------------------------
NITS
--------------------------------------------------------------------------

- The document expired on 1 September 2026 and needs a refresh.

- RFC 6286 is currently an Informative reference, but the Target BGP Identifier
  field is defined by reference to it, and its Section 2 is load-bearing for
  the identifier scope discussed in Major Issue 1(b). I suggest moving it to
  Normative References.

- Section 2: "with the high-order octet type set to 0x41" -- missing "of the",
  by contrast with the correctly worded transitive case in the preceding line.

- Section 3: "which may consists of one or multiple ASes" -> "consist".

- Section 3: "this node is not the target node of Update" -> "of the Update".

- Section 3: "In this section, the mechanism for intra-domain scenario is
  described, the mechanism for inter-domain scenario is for further study." --
  comma splice; suggest splitting into two sentences.

- Section 6: "which make it possible" -> "which makes it possible".

Thanks to the authors for a clear and readable document.

Regards,
Venkata Ramanaiah Chintha