Hi Robert, Please see inline [Bruno]
From: Robert Raszuk <rob...@raszuk.net> Sent: Thursday, March 6, 2025 11:10 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 Hi, Question (previously it was more of an observation :). Draft says: 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. Well - I think this is expressed way too weakly. Each area/level have at least two ABRs. So the proper procedure MUST be in place to assure that all such ABRs aggregate in the same way and allocate the same labels for the identical aggregates. Otherwise this will lead to a situation of different labels (including blocks) being advertised for the same aggregate prefix and then what do you do on ingress ? Pick first and risk no redundancy ? [Bruno] Ack. The comment is mostly aligned with the previous comment from Nat. Point taken. We Note however, that this document will not specify the protocol extension so procedures may be left to the protocol drafts. The crux of the matter here is how do you assure such strict symmetry ? Are we back at the world of manual configuration (analogy to static routing in large networks) ? [Bruno] Well, on egress nodes, the IP loopback and the SR-MPLS SID are indeed allocated by the network operator, one by one. (this may not be manual). And on the ABR, the definition of the aggregate is also defined by the network operator since this depends on its addressing plans. But indeed, for the MPLS range, I would rather not rely on configuration. Plus if we want to minimize MPLS FIB, hence reuse the SRGB space of the L1/IGP domain, configuration would not address the scenario brought by Nat. (changing the SRGB). So as replied to Nat, we’ll work on this and come back to the SPRING WG. Cheers, --Bruno Cheers, 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.
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
