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

Reply via email to