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 ? 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) ? Cheers, 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] >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
