Hi, From: Robert Raszuk <rob...@raszuk.net> Sent: Thursday, March 6, 2025 4:11 PM
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. Do you mean « UPA is not enough” or “Hint” is not enough. Assuming the later, we can’t force people to use UPA, plus IP aggregation existed before UPA. But we can rephrase to first express the drawback of aggregation (loss of individual reachability) and then refers to a solution. 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. We have the same amount of entropy (an individual label per specific FEC). The different is the additional top label for the MPLS hierarchy. Typically implementations hash multiple labels so this would not make a difference. (more bits, same entropy) Likewise what happens if PEs add entropy labels during aggregation ? For SR, ELC is signaled on a per prefix basis, since rfc9088. As aggregation hide the details of each prefix, ELC signaling on a per egress LER basis would be lost, just like all other prefix specific signaling. A priori this make sense to me since aggregation is about summarization, hence hiding the details. OTOH, the aggregation segment could probably be advertised with ELC, allowing for the use of EL from ingress LER up to egress ABR. Alternatively, if needed, the ingress LER could learn the specifics of the egress area using BGP-LS and hence learn ELC on a per egress LER basis. Bottom line is that IMO all pros and cons should be listed. Of IP aggregation that we are doing for 25+ years (e.g., details of each prefix is hidden)? Would you have a pointer to an existing document? (if it’s useful text, it probably have already been written in 25 years) Or only for the specific SR-MPLS aspects? Cheers, --Bruno Cheers, R. On Thu, Mar 6, 2025 at 3:55 PM <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote: Hi Robert, Thanks for the review and comments. Please see inline [Bruno] From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Sent: Thursday, March 6, 2025 10:38 AM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> 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 <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> ____________________________________________________________________________________________________________ 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
