Early Review of draft-ietf-idr-bgpls-inter-as-topology-ext-32
review-ietf-idr-bgpls-inter-as-topology-ext-32-rtgdir-early-stone-2026-05-29-00

Hello,

I have been selected to do a (second) routing directorate "early" review of
this draft.

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-inter-as-topology-ext/

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 is in 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 last call comments.

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

Document:        draft-ietf-idr-bgpls-inter-as-topology-ext-32
Reviewer:        Andrew Stone
Review Date:     2026-05-29
Intended Status: Standards Track

Summary:

  This document is basically ready for publication, but has nits that
  should be considered prior to being submitted to the IESG.

Comments:

  The document is fairly well written and clearly describes its use case
  and goals, along with the necessary encodings to BGP-LS and the
  expected behavior.

  The following comments attempt to address clarity and technical
  accuracy.

  1. Section 5 states that the "Identifier" values for the two
     half-links "could be different" depending on the configuration of
     Identifiers for the two IGP domains. But, in this inter-as scenario I believe they -must- be
     different. For a controller to discover the two independent IGP
     instances, each IGP instance needs a unique Identifier anyways otherwise
     the controller may mistakenly conflate the two as a discontiguous
     discovery of a single IGP domain. RFC9552 also states: "Unique BGP-LS Instance-IDs MUST be 
     assigned to routing protocol instances operating in different IGP domains" 

  2. The wording around the IPv4/IPv6 Remote ASBR ID requirements
     could use some consistency across sections. As currently written,
     it is not entirely clear whether both must be included, whether
     IPv4 is only a fallback, or whether either one alone is
     sufficient. Can the IPv4 TLV be omitted as long as the IPv6 TLV
     is carried, even if the node has an IPv4 address? Perhaps a
     re-wording to: "IPv4 OR IPv6 MUST be present. If
     both are known, then both MUST be present."

      Section 5:
        "One or both of IPv4 and IPv6 Remote ASBR ID using TLV 271
          and/or TLV 272, depending on whether the Remote ASBR is
          configured with one or both of the IPv4 and IPv6 TE
          Router-IDs."

      Section 6.3:
        "The IPv6 Remote ASBR ID TLV MUST be included if the
          neighboring ASBR has an IPv6 address. If the neighboring ASBR
          does not have an IPv6 address, the IPv4 Remote ASBR ID TLV
          MUST be included instead. Both an IPv4 Remote ASBR ID TLV and
          an IPv6 Remote ASBR ID TLV MAY be present in an inter-AS Link
          NLRI."

      Section 7:
        "IPv6 Remote ASBR ID and/or IPv4 Remote ASBR ID MUST be
          presented within the inter-AS Link NLRI"

  3. Section 5:
       "Use of any other TLVs as Local Node Descriptors or inter-AS
        Link Descriptors may cause challenges in the correlation of
        the two inter-AS Link NLRI half-links when the BGP-LS Producer
        implementations vary."

     It is unclear to me whether this text is an explanation as to why the
     previously listed TLVs are mandated, or a warning not to use any
     other TLVs. If a warning, this should perhaps be a declarative
     statement (ex: "MUST NOT use").

  4. Section 8: I believe "SB1 - TB1" should say "SB1 - TB2". 
     The final paragraph describes alignment
     for the "static" / "direct" cases, but omits the BGP EPE case. 
     In the example diagram the half-link from SB1 to TB2 could be a 
     BGP EPE Link NLRI (Protocol = BGP) while the half-link from TB2 to SB1
     could be an Inter-AS Link NLRI (Protocol = OSPF/IS-IS). If
     my understanding is correct, the document should explicitly
     state that this scenario requires the controller to correlate
     the half ends of a BGP EPE Link NLRI with an Inter-AS Link NLRI sourced from
     OSPF/IS-IS.

Nits:

  Section 5:  s/seeSection 11)/see Section 11/

  Section 7:  s/information is done is done in IGPs/information is done in IGPs/

  Section 8:  s/To retrieval the inter-AS/To retrieve the inter-AS/

Other:

  The IANA "BGP-LS NLRI Types" registry still labels Type 7 as
  "Stub Link NLRI" from an earlier revision when the codepoint was
  reserved. I assume this will be updated to "Inter-AS Link NLRI"
  later in the process.