[Idr] Re: WG adoption call for draft-lin-idr-sr-epe-over-l2bundle-07 (8/2 to 8/16)

["Dongjie (Jimmy)" <[e-mail]>]

Hi Sue and authors,

I've read the latest version of this document and think the function described is useful, and it is good to reuse existing TLVs when it makes sense.

During its presentation in IETF 119, I raised some comments about the difference between SR-MPLS and SRv6 in EPE and EPE L2 bundle. Here I'd like to elaborate my comments to see if the mechanisms could be further clarified and aligned.


1.       For SR-MPLS, three segment types are defined in RFC 9086 for EPE traffic steering at different granularities: Peer Node SID, PeerAdj SID, and PeerSet SID.

Both PeerAdj SID and Peer Node SID can be advertised with the Link NLRI. For Peer AdjSID, the link descriptors in the link NLRI MUST include the link local ID and the link remote ID, and the IPv4/IPv6 address of the interface are optional.

RFC 9086 also says: Each BGP session MUST be described by a PeerNode SID.  The description of the BGP session MAY be augmented by additional PeerAdj SIDs.

Then for a EBGP session over L2 bundle, does it mean in addition to a link NLRI associated with PeerNode SID, one additional link NLRI with PeerAdj SID and the L2 bundle member Attributes is always needed? Or is that possible to add the L2 bundle member attributes to a link NLRI associated with the PeerNode SID? Currently the document is not clear about this.


2.       For SRv6, as described in RFC 9514, the mechanism for EPE information advertisement is different from SR-MPLS. For the BGP EPE PeerAdj SID functionality, End.X SID is advertised with link NLRI, while PeerNode SID and PeerSet SID are advertised using SRv6 SID NLRI.



Section 7.2 of RFC 9514 says: The SRv6 BGP PeerNode SID TLV is a mandatory TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI advertised by BGP for the EPE functionality.



Then for a EBGP session over L2 bundle,  is one link NLRI with the End.X SID for PeerAdj and the L2 bundle member Attributes always needed? Or is that possible to add the L2 bundle member attributes to the BGP-LS attribute associated with the SRv6 PeerNode SID NLRI? Currently the document is not clear about this.



3.       For SR-MPLS, Adj SID is defined for IGP links, and PeerAdj SID is defined for BGP peering links, now PeerAdj SID is reused for EPE L2 bundle member link.



For SRv6, End.X is used for both IGP and BGP adjacency/peering link, and now End.X SID is further reused for EPE L2bundle member link. Although it is good to have the same SID type and TLV reused for L3 adjacency related behavior, not sure whether the alignment between SR-MPLS and SRv6 needs to be considered?



I know the descriptions in RFC 8986 and 9514 covers the usage of SRv6 End.X SID in L2 bundle members and BGP EPE cases, so this question is not directly about this draft, it is more about the applicability of End.X in general.



Best regards,

Jie

From: Susan Hares [mailto:[e-mail]]
Sent: Friday, August 2, 2024 10:12 PM
To: [e-mail]
Subject: [Idr] WG adoption call for draft-lin-idr-sr-epe-over-l2bundle-07 (8/2 to 8/16)

IDR WG:

This begins a 2 week WG adoption call for
draft-lin-idr-sr-epe-over-l2bundle-07.txt
https://datatracker.ietf.org/doc/draft-lin-idr-sr-epe-over-l2bundle/


The authors should reply to this email with an
IPR statement indicating whether they know of an intellectual property.

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.


In your comments regarding adoption,  please consider

1)  Does this BGP-LS addition help SR Egress Peering points

in operational networks?
2)  Does this draft handle the BUM traffic in a way that

Prevents looping?

(Broadcast, Unknown Unicast, and Multicast (BUM))
3)  Are there any problems in the technology described?

Cheerily, Sue Hares