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