Hi, Bruno. Thanks for the reply. Please refer to the inline [Nat3].
On Thu, Mar 6, 2025 at 5:36 PM <bruno.decra...@orange.com> wrote: > 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> wrote: > > Hi Nat, > > Thanks for your reply. > > I have one clarification question. Please see inline [Bruno2] > > > > *From:* Nat Kao <pyxi...@gmail.com> > *Sent:* Wednesday, March 5, 2025 4:53 AM > *To:* DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com> > *Cc:* SPRING WG <spring@ietf.org>; > 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> wrote: > > Hi Nat, > > > > Thanks for your review and the very good questions. > > > > Please see inline [Bruno] > > > > *From:* Nat Kao <pyxi...@gmail.com> > *Sent:* Tuesday, March 4, 2025 10:59 AM > *To:* DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com> > *Cc:* SPRING WG <spring@ietf.org>; > 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. > [Nat3] Agreed. This case can be a non-goal of this draft. In my opinion, maybe just a recommendation on the consistency of SRGBs should be enough. > 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 > > > I had some experience with the SRGB migration process, and that function works well in a live network.;) > > > 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. > [Nat3] Yes. Optimal allocation can be done in the first place, so this should be a rare case(hopefully). We can also mention this in the protocol extensions to avoid ambiguous behaviors between implementations. > 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, Nat > > > 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> 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 <internet-dra...@ietf.org> > Sent: Monday, March 3, 2025 5:18 PM > To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>; Kamran Raza < > skr...@cisco.com>; Ketan Talaulikar <ketant.i...@gmail.com>; Shraddha > Hegde <shrad...@juniper.net>; Syed Raza <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 > To unsubscribe send an email to 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
