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. > > > 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. > >
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
