I support publishing this draft. I believe this draft will be extremely valuable for operators in cases of bundles with member links taking diverse latency paths and being able to steer across the lower latency member links.
SR framework utilizes the IGP to distribute Sid’s eliminating LDP and RSVP-TE adjacency per hop state which is the core foundation of segment routing. So there can be massive IGP domains with Tier-1 ISPs or MSDC DC POD design with massive IGP domains and in those cases the flooding is already being done with SR technology. There are flood optimizations being worked on in LSR ongoing as well as the published Flood reflection RFC 9377 and Area Proxy RFC 9666 to help the IGP scale with massive L2 backbones. This drafts L2 bundle member mechanism purposely compliments the existing RFC 8668 which advertises the local L2 member links as adj-Sid, where this draft completes the local to remote port wiring construct so that L2 member link adj Sid can be successfully used in the SR policy steering. By utilizing the SR methodology, IGP to flood the remote ports it allows the operator the flexibility to use SR head end local policy for steering and not have to relay on a controller. Kind Regards Gyan On Wed, Aug 5, 2026 at 11:55 AM Acee Lindem via Datatracker < [email protected]> wrote: > This message starts a WG Last Call for: > draft-ietf-lsr-l2-bundle-member-remote-id-03 > > This Working Group Last Call ends on 2026-08-19 > > Abstract: > In networks where Layer 2 (L2) interface bundles (such as a Link > Aggregation Group (LAG) as defined in IEEE 802.1AX) are deployed, a > controller may need to collect the connectivity relationships between > bundle members for traffic engineering (TE) purposes. For example, > when performing topology management and bidirectional path > computation for TE, it is essential to know the connectivity > relationships among bundle members. > > This document describes how OSPF and IS-IS would advertise the remote > interface identifiers for Layer 2 bundle members. The corresponding > extension of BGP-LS is also specified. > > File can be retrieved from: > > https://www.ietf.org/archive/id/draft-ietf-lsr-l2-bundle-member-remote-id-03.txt > > Please review and indicate your support or objection to proceed with the > publication of this document by replying to this email keeping > [email protected] > in copy. Objections should be explained and suggestions to resolve them are > highly appreciated. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [1]. > Appropriate IPR disclosures required for full conformance with the > provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-lsr-l2-bundle-member-remote-id/ > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-lsr-l2-bundle-member-remote-id-03.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-l2-bundle-member-remote-id-03 > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
