HI, I would just highlight that this draft enhances the scalability of the control plane and data plane of SR-MPLS networks by introducing a new level of hierarchy/indirection. That is achieved by prefix and label aggregation by ABRs.
On the other hand as there is no free lunch it removes the atomic signalling of remote PE failures from the network. I recall this was (maybe still is) most important reason why some folks were against LDP FEC aggregation. Yes you hinted that "optionally" one can use UPA as a replacement/workaround for such atomic route suppression. Is this hint enough ? Not sure. Also I am quite not convinced if you will get the same level of ECMP when using aggregated labels to ABRs in all network gear as compared with atomic labels. Likewise what happens if PEs add entropy labels during aggregation ? Bottom line is that IMO all pros and cons should be listed. Cheers, R. On Thu, Mar 6, 2025 at 3:55 PM <[email protected]> wrote: > Hi Robert, > > > > Thanks for the review and comments. > > Please see inline [Bruno] > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Thursday, March 6, 2025 10:38 AM > *To:* DECRAENE Bruno INNOV/NET <[email protected]> > > Hi, > > > > Very nice ! > > > > But is there a reason why this approach would not work for vanilla LDP ? > > > > If ABRs can aggregate MPLS labels and generate aggregate SID they could as > well generate aggregate FECs. > > And we do have for years the ability to use LPM for MPLS too. > > > > Of course perhaps folks are moving away from LDP these days and jump on to > SR, but I am curious if there > > is a similar proposal in respect to MPLS with LDP. > > > > [Bruno] I don’t see why this wouldn’t also work for LDP; but I haven’t > looked at it. > > I’m not planning to do the work for LDP, you are welcome to propose a > draft (presumably in the MPLS WG) > > > > > > With the above you statement in Abstract and Info while atomically correct > is opaque to the draft: > > > > "Contrary to this, MPLS forwarding works on exact match on MPLS labels." > > > > In all cases there would be an exact match in the data plane. But the > control plane in both can use LPM too > > to select which label(s) to put on the stack. > > > > [Bruno] I guess your point is that this draft does not change the > forwarding plane hence talking about forwarding plane in the abstract is a > distraction. > > The motivation was to explain the reason why we all like and use IP > aggregation, while we don’t do it in MPLS. But having only a few words in > the abstract make the exercise difficult. > > May be an option would be avoid referring to the data plane, and to the > reasons why this was not done. And only introduce what the document propose > to achieve, and possibly how. > > I don’t have proposals right now. We’ll have to thing about it. > > > > Thanks, > > --Bruno > > > > Best, > > R. > > > > > > On Mon, Mar 3, 2025 at 9:32 PM <[email protected]> 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: [email protected] <[email protected]> > Sent: Monday, March 3, 2025 5:18 PM > To: DECRAENE Bruno INNOV/NET <[email protected]>; Kamran Raza < > [email protected]>; Ketan Talaulikar <[email protected]>; Shraddha > Hegde <[email protected]>; Syed Raza <[email protected]> > 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 -- [email protected] > To unsubscribe send an email to [email protected] > > ____________________________________________________________________________________________________________ > 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 -- [email protected] To unsubscribe send an email to [email protected]
