[Idr] Re: draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle-03 early Rtgdir review

["Andrew Stone (Nokia)" <[e-mail]>]

Hi Changwang, authors,

Thanks for the document update. Looks good to me, consider my comments addressed and closed.

Thanks!
Andrew

From: linchangwang <[e-mail]>
Date: Monday, June 8, 2026 at 8:51 AM
To: Susan Hares <[e-mail]>; Andrew Stone (Nokia) <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle-03 early Rtgdir review


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi Andrew,

Thank you for your review.
We appreciate your thoughtful comments and suggestions.

All your comments have been addressed in latest version.
Link: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle/04/
Diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle-03&url2=draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle-04&difftype=--html


Pls check and let us know if there are any further comments.

Thanks,
Changwang

-----邮件原件-----
发件人: Susan Hares <[e-mail]>
发送时间: 2026年6月6日 6:11
收件人: Andrew Stone <[e-mail]>; [e-mail]
抄送: [e-mail]; [e-mail]
主题: RE: draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle-03 early Rtgdir review



Andrew:

Thank you for your excellent RTGDIR.

Cheerily, Sue Hares

-----Original Message-----
From: Andrew Stone via Datatracker <[e-mail]>
Sent: Friday, June 5, 2026 3:52 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle-03 early Rtgdir review

Document: draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle
Title: Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members
Reviewer: Andrew Stone
Review result: Has Issues

Hello

I have been selected to do a routing directorate early review of this draft.

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__wiki.ietf.org_en_group_rtg_RtgDir%26d%3DDwICaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D3QxUPy-fV0G16Z4tIRByiA%26m%3DRLJH_KNT9X5t6dOeIzCJXhdvFp7qOE08e8NSF9_Zcpq8emMTigrhgNlK_xIXkGkh%26s%3DNmcMOPb1riMmPhdCfva3eGNl6btRfasX0DqyrRSSfTQ%26e%3D&data=05%7C02%7Candrew.stone%40nokia.com%7Cfd9327df58474334287d08dec55c9aa5%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639165198748537751%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xTdALovu3fY5oTISnxbPK1yz5YsyYgwaPfiUeOAqCa4%3D&reserved=0<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_en_group_rtg_RtgDir&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=RLJH_KNT9X5t6dOeIzCJXhdvFp7qOE08e8NSF9_Zcpq8emMTigrhgNlK_xIXkGkh&s=NmcMOPb1riMmPhdCfva3eGNl6btRfasX0DqyrRSSfTQ&e=>

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



-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。
禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。
如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above.
Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited.
If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!