Early Review of draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle-03
review-ietf-idr-bgp-ls-sr-epe-over-l2bundle-03-rtgdir-early-stone-2026-06-05-00

Hello

I have been selected to do a routing directorate early review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle/

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 has just passed 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-bgp-ls-sr-epe-over-l2bundle-03
Reviewer:        Andrew Stone
Review Date:     2026-06-05
Intended Status: Standards Track

Summary:

  I have some minor concerns about this document that I think should be
  resolved before it is submitted to the IESG.

  Thanks for work on this document. The document is generally well written and
  is very clear on its goals and leverages existing encoding semantics to bring
  in new functionality without having to define new.

Comments:

  1. Recommendation: I believe the abstract can be condensed to what/how and
  does not need to dive into the why as much:

        OLD

            There are deployments where the Layer 3 interface on which a BGP
            peer session is established is a Layer 2 interface bundle.  In
            order to allow BGP-EPE to control traffic flows on individual
            member links of the underlying Layer 2 bundle, BGP Peering SIDs
            need to be allocated to individual bundle member links, and
            advertisement of such BGP Peering SIDs in BGP-LS is required.  This
            document describes how to support Segment Routing BGP Egress Peer
            Engineering over Layer 2 bundle members.  This document updates
            RFC9085 to allow the L2 Bundle Member Attributes TLV to be added to
            the BGP-LS Attribute associated with the Link NLRI of BGP peering
            link.  This document updates RFC9085 and RFC9086 to allow the
            PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member
            Attributes TLV.

            NEW

           This document describes how to support Segment Routing BGP Egress
           Peer Engineering over Layer 2 bundle members.  It updates RFC 9085
           to allow the L2 Bundle Member Attributes TLV in the BGP-LS Attribute
           of the Link NLRI for a BGP peering link, and updates RFC 9085 and
           RFC 9086 to allow the PeerAdj SID TLV as a sub-TLV of the L2 Bundle
           Member Attributes TLV.

  2. Section 2: The sentence is a bit misleading to say "in order to support
  BGP EPE".
     BGP EPE is already supported over l2 bundles, what is not supported is
     the steering over explicit, specific members within the bundle.

            OLD
            In order to support BGP Egress Peer Engineering over Layer 2 bundle
            members,

            NEW
            In order to support BGP Egress Peer Engineering steering over
            specific Layer 2 bundle members,

  3. This is why I tagged "has issues": Section 3/3.1: Is Peer Set supported?
  It's only referenced as the EPE capability
     in an earlier section but all examples focus on Peer Adjacency. For
     example, could someone assign 2 members to Peer Set 1, and 2 other members
     to Peer Set 2?  Please clarify whether PeerSet SID is in scope or not. If
     in scope, describe any effects or differences to the encoding (if any).

  4. Section 3.1:  paragraph 2 has the use of 'must' and 'must not' here that
  should probably be
     'MUST' and MUST NOT, unless the intent was not to do that because it's
     restating
      what is desacribed in RFC9086?

  5. Thanks for moving the Cross WG section to Appendix in -03. I was going to
  suggest the same from my earlier read
     of -02 before I had a chance to write this up, but it's already done.

Nits:

   None found. Few grammatical tweaks could be performed but IETF editor would
   be better suited for recommendations.

Thanks,
Andrew