Hi Nat, Thanks for your reply and clarifications. Please see inline [Bruno3]
From: Nat Kao <pyxi...@gmail.com> Sent: Thursday, March 6, 2025 3:48 AM Hi, Bruno. Many thanks for the reply. Please refer to the inline[Nat2]: On Wed, Mar 5, 2025 at 10:45 PM <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote: Hi Nat, Thanks for your reply. I have one clarification question. Please see inline [Bruno2] From: Nat Kao <pyxi...@gmail.com<mailto:pyxi...@gmail.com>> Sent: Wednesday, March 5, 2025 4:53 AM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; draft-decraene-spring-sr-mpls-aggregation-segm...@ietf.org<mailto:draft-decraene-spring-sr-mpls-aggregation-segm...@ietf.org> Subject: Re: [spring] draft-decraene-spring-sr-mpls-aggregation-segment-00 Hi, Bruno. Thanks for the reply. Please refer to the inline [Nat]. On Tue, Mar 4, 2025 at 9:37 PM <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote: Hi Nat, Thanks for your review and the very good questions. Please see inline [Bruno] From: Nat Kao <pyxi...@gmail.com<mailto:pyxi...@gmail.com>> Sent: Tuesday, March 4, 2025 10:59 AM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; draft-decraene-spring-sr-mpls-aggregation-segm...@ietf.org<mailto:draft-decraene-spring-sr-mpls-aggregation-segm...@ietf.org> Subject: Re: [spring] draft-decraene-spring-sr-mpls-aggregation-segment-00 Hi, Bruno. Thanks for the draft. It's helpful to aggregate SIDs based on prefixes in an SR-MPLS network. I have a few questions regarding this draft: -In section 5, should the signaling direction be in the reversing order? (I may have missed something here) Ex: in section 5.1: -For the aggregation segment (192.0.2/24): PE2.3 => P2 => ABR2 => P0 => ABR1 -For the specific segment toward PE2.x: PE2.3 => P2 => ABR2 => P0 => ABR1 => P1 => PE1 [Bruno] Good catch. Fixed in my local repo. [Nat] Thanks! -This may be a little bit out of the scope of this draft. If there are multiple aggregation segment advertisements with different label-related parameters(Sub-TLVs), how should we deal with them? Should we only use ones that include the reachability to the egress PE as ECMP legs or ignore aggregation segments with inconsistent parameters altogether? [Bruno] Very good point. I’m assuming that you are referring to multiple aggregation segments for the same IP aggregate. [Nat] Yes. First, the draft is calling for not doing this: “If the same Aggregation segment is advertised by multiple nodes, it becomes an anycast segment. Absent specific provisions (e.g., context specific label) such anycast segment needs to advertise the same labels related parameters (first prefix, the absolute label associated with that first prefix) for all instances.” [Nat] I see. During the migration of the Specific Segment ranges with redundant SRMSs/ASBRs/L1L2 Routers, there may be a short period of inconsistency for the advertisements. We can alleviate this migration by careful provisioning beforehand, so it's probably not too disruptive. [Bruno2] I’m not sure to see the migration scenario that you have in mind. Could you please elaborate on this migration scenario? From my perspective, · redundant L1L2 routers would be in the same L1 area as they advertise the same aggregate for the same destinations / Prefix Segment. · Hence they would see the same Prefix SID (index) for a specific prefix segment in their L1 · Assuming that they have the same SRGB (which is a general recommendation for SR-MPLS from day 1 (cf RFC8402 §2)) they would use the same label value for a given specific segment · In order to minimize their FIB size, they would simply advertise those same labels for the Aggregation Segment So the problematic migration would be the change of SRGB on those routers (i.e., changing the value of the first label in the SRGB. As increasing the SRGB by increase the label label would not be an issue) Is this the scenario that you had in mind? [Nat2] Yes. That's one of the cases that came to my mind when merging other networks with different SRGBs. If we migrate the SRGB before the merging process, this problem won't happen. [Bruno3] OK. Thanks for clarifying. IMHO, the occurrence of this migration scenario is relatively rare but can definitely happen in the life of networks. As a network operator, I can definitely relate… Again, going point. Thank you for raisin it. We’ll discuss this between authors. At this point, no commitment as simplicity is also a goal. Note also that modifications of SRGBs are touchy from day 1. E.g. there is some text about this in https://datatracker.ietf.org/doc/html/rfc8667#section-3.1 The other case occurs if we only do partial allocation(probably not recommended?) and then expand later: Ex: Before migration: Aggregated Prefix: 192.0.2/24 Aggregation SID: 1000 First Label: 1200 Range: 128 After migration: Option 1: Aggregated Prefix: 192.0.2/24 Aggregation SID: 1000 First Label: 1200 Range: 255 Option 2: Aggregated Prefix: 192.0.2/24 Aggregation SID: 1000 First Label: 1200 Range: 128 First Label: 1328 Range: 127 [Bruno3] So far (-00 …) has a text about (against 😉 ) this in this ops section “IP Aggregation on border routers requires IP addresses to be aggregatable hence contiguous. Segment aggregation additionally requires that segment ID are allocated in an ordered and contiguous way. This is aligned with the definition and encoding of the Mapping Server as defined in [RFC8667<https://www.rfc-editor.org/rfc/rfc8667>] section 2.4.” https://datatracker.ietf.org/doc/html/draft-decraene-spring-sr-mpls-aggregation-segment-00#name-network-operation-considera Also this seems to go against operational simplicity. On our side, at my company, people like to be able to derive the SID from the IP address. With the addition of a common SRGB, this really simplify operations. (e.g., easier to detect a misconfiguration of a LFBI mis programming). Also a /24 255 range does not seem that big to me, I would personally not bother optimizing below this. That being said, everyone is free to allocate it it’s IP addresses and SID the way they want. Yet, aggregation require some constraints, by definition. If so, a priori I agree that this would be a case where redundant Aggregation Segments could transiently need to advertise different labels related parameters. We may need to think more about this case. First reaction would be that, as indicated in the draft, this is general to anycast SID rather than specific to Aggregation segment. SPRING WG used to have a WG doc related to anycast segment. AFAIK, the interested faded as the simplest way and the consensus seemed to use the same SRGB for nodes advertising anycast SID. (the alternative was using context labels, which is additional implementation work) [1] https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-anycast-segments Otherwise, may be the Aggregation Segment signaling could be designed to accommodate this transition scenario. E.g., the label parameters encoded in a sub-TLV attached to the Aggregation Segment and the ingress would pick the label from the one on its shortest path? We need to think about this transition scenario. [Nat2] That's probably a reasonable approach. Maybe we should mention the detailed procedures with inconsistent label parameters in the protocol extensions. [Bruno3] Yes. At some point the discussion is futile without knowing the protocol extensions. But it’s good to bring the point before the protocol extension, to try to accommodate it. Thanks, --Bruno Thanks, --Bruno Many thanks, Nat Second, the protocols/signaling aspects are still very open for discussion. Drafts currently refers to two possible paths: “could be signaled in different ways e.g., as sub-TLV of the aggregate prefix advertisement, or as a separate advertisement on the lines of a Segment Routing Mapping Server (SRMS).” We’d like to have feedback on this. What would be your preference? This may affect the answer to your question. E.g. the SRMS style advertisement would be independent of the IP aggregate advertisement and could include a Preference (just like the current SRMS) or any other tie-breaking rule. [Nat] I see. IMO, both solutions work. I don't have specific preferences here. The Sub-TLV style advertisement might align better with the traditional IGP/BGP aggregate approach, while the separate advertisement approach aligns better with the mapping server. Thanks, Regards, --Bruno Many thanks! Nat Many thanks! Nat On Tue, Mar 4, 2025 at 4:30 AM <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote: [obviously speaking as individual contributor] Hi all, We have just published a short draft. It introduces an Aggregation Segment for Segment Routing with MPLS data plane. This can be used to aggregate IP prefixes along with their SR Prefix Segments. Aggregation Segments enable aggregation of IP prefixes to be performed at border routers to improve scalability of MPLS networks. We would appreciate your review and comments. Thanks, --Shraddha, Ketan, Kamran, Bruno -----Original Message----- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Sent: Monday, March 3, 2025 5:18 PM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>; Kamran Raza <skr...@cisco.com<mailto:skr...@cisco.com>>; Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>>; Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; Syed Raza <skr...@cisco.com<mailto:skr...@cisco.com>> Subject: New Version Notification for draft-decraene-spring-sr-mpls-aggregation-segment-00.txt A new version of Internet-Draft draft-decraene-spring-sr-mpls-aggregation-segment-00.txt has been successfully submitted by Bruno Decraene and posted to the IETF repository. Name: draft-decraene-spring-sr-mpls-aggregation-segment Revision: 00 Title: SR-MPLS Aggregation Segment Date: 2025-03-03 Group: Individual Submission Pages: 9 https://www.ietf.org/archive/id/draft-decraene-spring-sr-mpls-aggregation-segment-00.html Abstract: One of the key features of IP that has helped IP Routing to scale is aggregation of IP prefixes. This is made possible with longest-match lookup in IP forwarding. Contrary to this, MPLS forwarding works on exact match on MPLS labels. This poses a challenge in aggregation of IP prefixes when the forwarding is based on the MPLS labels associated with those IP prefixes. This document introduces an Aggregation Segment for Segment Routing with MPLS data plane which can be used to aggregate IP prefixes along with their SR Prefix Segments. Aggregation Segments enable aggregation of IP prefixes to be performed at border routers to improve scalability of MPLS networks. The IETF Secretariat ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list -- spring@ietf.org<mailto:spring@ietf.org> To unsubscribe send an email to spring-le...@ietf.org<mailto:spring-le...@ietf.org> Orange Restricted ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
