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

[linchangwang <[e-mail]>]

Hi Jie,

Sorry for the delayed reply.
Thank you for your thoughtful question.
Regarding the BGP EPE L2 Bundle information, it is part of the peer adj NLRI attribute.
For detailed SR-MPLS and SRv6 examples, please refer to Appendix A.

Here are the specific reasons:

  1.  The L2 Bundle information, as defined in RFC 9085, being part of a three-layer logical interface, is more appropriately placed under the peer adj NLRI.
  2.  For non-directly connected EBGP neighbors, it must be placed under the peer adj NLRI attribute.
  3.  For SR-MPLS with directly connected EBGP neighbors, while it can also be placed under the peer node NLRI, the peer node NLRI does not contain interface information. Therefore, it is not appropriate to place the L2 Bundle attribute under the peer node NLRI.
  4.  For SRv6, the peer node is an attribute of the SRv6 SID NLRI, where the NLRI contains the SRv6 SID of the peer node or peer set.

In Appendix A of RFC 9514, different considerations for SRv6 are explained, with the peer node or peer set, which are unrelated to the three-layer interface, placed as an attribute under SRv6 SID NLRI. Therefore, the BGP EPE L2 Bundle information, as a complement to the three-layer interface information, is more suitably placed under the peer adj NLRI.


Therefore, whether it is SR-MPLS or SRv6, BGP EPE L2 Bundle information is advertised as an attribute of peer adj NLRI.
In the next version, we will provide additional explanations regarding the placement of the BGP EPE L2 Bundle information,
particularly concerning directly connected EBGP neighbors. Thank you.

For a detailed explanation,  please refer to the notes below: [Changwang].

Thanks,
Changwang

发件人: Dongjie (Jimmy) <jie.dong=[e-mail]>
发送时间: 2024年8月9日 17:08
收件人: Susan Hares <[e-mail]>; [e-mail]
主题: [Idr] Re: WG adoption call for draft-lin-idr-sr-epe-over-l2bundle-07 (8/2 to 8/16)

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.

[Changwang]
For SR-MPLS:
The generated NLRI and attribute information are as follows:
1.Peer Node (NLRI) Information:

  *   Local RouterID
  *   AS Number
  *   Peer RouterID
  *   Peer AS Number
  *   Local /Remote TCP Peer Address
  *   Corresponding Attributes:
     *   Peer Node Adjacency

  1.  Peer ADJ (NLRI) Information:

  *   Local RouterID
  *   AS Number
  *   Peer RouterID
  *   Peer AS Number
  *   Local Interface Index
  *   Remote Interface Index
  *   Local/Remote  IPv4 Address (optional)
  *   Corresponding Attributes:
     *   Peer Link Adjacency(optional)
     *   L2 Bundle Information
        *   Member #1: Peer Adjacency
        *   Member #2: Peer Adjacency
For SR-MPLS , directly connected EBGP neighbors, the L2 Bundle information can be placed under either the peer node NLRI or the peer adjacency NLRI.
For non-directly connected EBGP neighbors, the L2 Bundle information must be placed under the peer adjacency NLRI attributes.
Considering that L2 Bundle information is inherently associated with layer 3 interface information, it is clearer to place the L2 Bundle information under the peer adjacency NLRI in SR-MPLS.
The L2 Bundle of EPE is generated as a peer adj NLRI attribute and does not alter the original behavior of peer node and peer adj generation.
For detailed SR-MPLS examples, you can refer to Appendix A.


  1.  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.



[Changwang]
For SRv6, the generated NLRI and attribute information are as follows:
1. SRv6 Node NLRI Information:

  *   Local RouterID
  *   AS Number
  *   SRv6 SID
  *   Corresponding Attributes:
     *   Peer EPE AS Node Information:
        *   Peer RouterID
        *   Peer AS Number
        *   Weight
        *   Flag (indicating whether it is a Node or a Set)
For SRv6 BGP EPE, the Peer Node or Peer Set information is included within the SRv6 Node attributes.
Within the SRv6 BGP EPE Peer Node, there is no information about neighbor addresses, local addresses, or local interface indexes.
Therefore, it is not appropriate to place L2 Bundle information under the SRv6 Node attributes.

2. Peer Adj NLRI Information:

  *   Local RouterID
  *   AS Number
  *   Peer RouterID
  *   Peer AS Number
  *   Local Interface Index
  *   Remote Interface Index
  *   Local TCP Peer Address (optional)
  *   Corresponding Attributes:
     *   end.x(optional)
     *   L2 Bundle Information (Newly added BGP EPE Bundle information should be placed under the peer adj NLRI attributes):
        *   Member #1: end.x
        *   Member #2: end.x

From the above, it can be seen that in the case of SRv6, the peer node is advertised based on the SRv6 SID NLRI, and SRv6 BGP PeerNode SID TLV(as defined in RFC 9514)does not include local addresses or neighbor address information. Therefore, it is not suitable to place L2 Bundle information(including SRv6 SIDs for member ports)  under the SRv6 Node NLRI’s attributes.  The L2 Bundle of EPE is generated as a peer adj NLRI attribute.

You can refer to Appendix A for detailed SRv6 examples.




  1.  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.

[Changwang] This issue might be related to the initial design and is not directly related to this document.

We can have a more detailed discussion about it if needed.

Thank you.





Best regards,

Jie

From: Susan Hares [mailto:[e-mail]]
Sent: Friday, August 2, 2024 10:12 PM
To: [e-mail]<mailto:[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?

  1.  Does this draft handle the BUM traffic in a way that

Prevents looping?

(Broadcast, Unknown Unicast, and Multicast (BUM))

  1.  Are there any problems in the technology described?

Cheerily, Sue Hares
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
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!