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

[linchangwang <[e-mail]>]

Hi Sue,

       I have submitted version-08.
Link: https://datatracker.ietf.org/doc/draft-lin-idr-sr-epe-over-l2bundle/08/

Key changes made are as follows:
Added detailed information about NLRI and its attributes in Sections 3.1 and 3.2.

Please review. Thanks!

Thanks,
Changwang

发件人: Susan Hares <[e-mail]>
发送时间: 2024年8月23日 20:47
收件人: Dongjie (Jimmy) <[e-mail]>; linchangwang (RD) <[e-mail]>; [e-mail]
主题: RE: WG adoption call for draft-lin-idr-sr-epe-over-l2bundle-07 (8/2 to 8/16) - Extended to 8/30.

Changwang and Jie:

Thank you for the good discussion on list.  Prior to adoption, the IDR chairs would like to see a revision of this draft (draft-lin-idr-sr-epe-over-l2bundle-08) with the changes discussed below.  Please submit the changes in draft-lin-idr-sr-epe-over-l2bundle-08.

We’ll review this version and then complete the adoption call.

Sue

From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, August 18, 2024 9:48 PM
To: linchangwang <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: WG adoption call for draft-lin-idr-sr-epe-over-l2bundle-07 (8/2 to 8/16)


Hi Changwang,

Thanks for the detailed explanation with examples. Most of them makes sense to me. And it is suggested the text in this document could be tightened to avoid potential inconsistency in understanding and implementation.

Please see further replies inline:

From: linchangwang <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 15, 2024 9:06 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: WG adoption call for draft-lin-idr-sr-epe-over-l2bundle-07 (8/2 to 8/16)

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.

[Jie] I got your point. It would be more accurate to say it is appropriate to have the L2 bundle information associated with the link NLRI of its parent layer-3 interface.


  1.  For non-directly connected EBGP neighbors, it must be placed under the peer adj NLRI attribute.

[Jie] When there are multiple interconnecting links for a multi-hop EBGP session using loopback addresses, for each link the PeerAdj SID needs to be advertised. If one of the links is L2 bundle, then the L2 bundle information should be carried as the attribute of the corresponding link NLRI.

It is also possible that the multi-hop EBGP session is established over a single link. In that case, the PeerAdj SID can also be optional, right? Then for L2 bundle over EPE, is an additional link NLRI with PeerAdj SID and L2 bundle information always needed? If so, I’d suggest to make this clear in the draft.


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

[Jie] With one-hop directly connected EBGP peers, the link NLRI with PeerNode SID represents the interconnecting link for the BGP session, and the local and remote IP addresses of the peering interfaces are carried in the link descriptors, This makes the link NLRI with PeerAdj SID optional.

If the link is an L2 bundle, it seems this document requires to advertise an additional link NLRI with a PeerAdj SID, and the associated L2 bundle information. If this is the case, it is suggested make this clear in the draft, and also clarify for such link NLRI whether the PeerAdj SID is needed or not, as its function would be the same as the PeerNode SID for the same BGP session, and the major purpose of this link NLRI is to advertise the SIDs for the L2 bundle member links.


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


[Jie] Yes, for SRv6 the advertisement of PeerNode SID and PeerSet SIDs are different from that in SR-MPLS, while please note that in RFC 9514 their endpoint behavior is also End.X, which means End.X SIDs could be advertised either with the link NLRI or using SRv6 SID NLRI.

I agree it is more appropriate to have the L2 bundle information (and the SIDs of member links) associated with its parent layer-3 interface and advertised with the link NLRI.

The remaining question is: if the BGP peer is established over a single L3 link (no matter single-hop or multi-hop), and the link is an L2 bundle, should the End.X SID representing the L3 link for this BGP peer be advertised with the link NLRI or using the SRv6 SID NLRI?  It is suggested to make this clear in the draft.

Best regards,
Jie


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]<mailto:jie.dong=[e-mail]>>
发送时间: 2024年8月9日 17:08
收件人: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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!