Hi Nat,
Thanks for your review and the very good questions.
Please see inline [Bruno]
From: Nat Kao <pyxi...@gmail.com>
Sent: Tuesday, March 4, 2025 10:59 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
Subject: Re: [spring] draft-decraene-spring-sr-mpls-aggregation-segment-00
Hi, Bruno.
Thanks for the draft. It's helpful to aggregate SIDs based on prefixes in an
SR-MPLS network.
I have a few questions regarding this draft:
-In section 5, should the signaling direction be in the reversing order?
(I may have missed something here)
Ex: in section 5.1:
-For the aggregation segment (192.0.2/24):
PE2.3 => P2 => ABR2 => P0 => ABR1
-For the specific segment toward PE2.x:
PE2.3 => P2 => ABR2 => P0 => ABR1 => P1 => PE1
[Bruno] Good catch. Fixed in my local repo.
-This may be a little bit out of the scope of this draft. If there are multiple
aggregation segment advertisements with different label-related
parameters(Sub-TLVs), how should we deal with them? Should we only use ones
that include the reachability to the egress PE as ECMP legs or ignore
aggregation segments with inconsistent parameters altogether?
[Bruno] Very good point. I’m assuming that you are referring to multiple
aggregation segments for the same IP aggregate.
First, the draft is calling for not doing this: “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.”
Second, the protocols/signaling aspects are still very open for discussion.
Drafts currently refers to two possible paths: “could be signaled in different
ways e.g., as sub-TLV of the aggregate prefix advertisement, or as a separate
advertisement on the lines of a Segment Routing Mapping Server (SRMS).”
We’d like to have feedback on this. What would be your preference?
This may affect the answer to your question. E.g. the SRMS style advertisement
would be independent of the IP aggregate advertisement and could include a
Preference (just like the current SRMS) or any other tie-breaking rule.
Thanks,
Regards,
--Bruno
Many thanks!
Nat
On Tue, Mar 4, 2025 at 4:30 AM
<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>
Orange Restricted
____________________________________________________________________________________________________________
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
