Hi, Bruno.
Many thanks for the reply.
Please refer to the inline[Nat2]:
On Wed, Mar 5, 2025 at 10:45 PM <bruno.decra...@orange.com> wrote:
> Hi Nat,
>
Thanks for your reply.
>
> I have one clarification question. Please see inline [Bruno2]
>
>
>
> *From:* Nat Kao <pyxi...@gmail.com>
> *Sent:* Wednesday, March 5, 2025 4:53 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 reply.
> Please refer to the inline [Nat].
>
>
>
> On Tue, Mar 4, 2025 at 9:37 PM <bruno.decra...@orange.com> wrote:
>
> 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.
>
> [Nat]
>
> Thanks!
>
> -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.
>
>
>
> [Nat]
>
> Yes.
>
>
>
> 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.”
>
>
>
> [Nat] I see.
>
> During the migration of the Specific Segment ranges with redundant
> SRMSs/ASBRs/L1L2 Routers, there may be a short period of inconsistency for
> the advertisements.
> We can alleviate this migration by careful provisioning beforehand, so
> it's probably not too disruptive.
>
>
>
> [Bruno2] I’m not sure to see the migration scenario that you have in mind.
> Could you please elaborate on this migration scenario?
>
>
>
> From my perspective,
>
> - redundant L1L2 routers would be in the same L1 area as they
> advertise the same aggregate for the same destinations / Prefix Segment.
> - Hence they would see the same Prefix SID (index) for a specific
> prefix segment in their L1
> - Assuming that they have the same SRGB (which is a general
> recommendation for SR-MPLS from day 1 (cf RFC8402 §2)) they would use the
> same label value for a given specific segment
> - In order to minimize their FIB size, they would simply advertise
> those same labels for the Aggregation Segment
>
>
>
> So the problematic migration would be the change of SRGB on those routers
> (i.e., changing the value of the first label in the SRGB. As increasing the
> SRGB by increase the label label would not be an issue)
>
>
>
> Is this the scenario that you had in mind?
>
[Nat2]
Yes.
That's one of the cases that came to my mind when merging other networks
with different SRGBs.
If we migrate the SRGB before the merging process, this problem won't
happen.
The other case occurs if we only do partial allocation(probably not
recommended?) and then expand later:
Ex:
Before migration:
Aggregated Prefix: 192.0.2/24
Aggregation SID: 1000
First Label: 1200
Range: 128
After migration:
Option 1:
Aggregated Prefix: 192.0.2/24
Aggregation SID: 1000
First Label: 1200
Range: 255
Option 2:
Aggregated Prefix: 192.0.2/24
Aggregation SID: 1000
First Label: 1200
Range: 128
First Label: 1328
Range: 127
> If so, a priori I agree that this would be a case where redundant
> Aggregation Segments could transiently need to advertise different labels
> related parameters.
>
> We may need to think more about this case.
>
> First reaction would be that, as indicated in the draft, this is general
> to anycast SID rather than specific to Aggregation segment. SPRING WG used
> to have a WG doc related to anycast segment. AFAIK, the interested faded as
> the simplest way and the consensus seemed to use the same SRGB for nodes
> advertising anycast SID. (the alternative was using context labels, which
> is additional implementation work)
>
> [1]
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-anycast-segments
>
>
>
>
>
> Otherwise, may be the Aggregation Segment signaling could be designed to
> accommodate this transition scenario. E.g., the label parameters encoded in
> a sub-TLV attached to the Aggregation Segment and the ingress would pick
> the label from the one on its shortest path?
>
> We need to think about this transition scenario.
>
[Nat2]
That's probably a reasonable approach.
Maybe we should mention the detailed procedures with inconsistent label
parameters in the protocol extensions.
>
>
> Thanks,
>
> --Bruno
>
>
>
Many thanks,
Nat
>
>
>
>
> 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.
>
>
>
> [Nat] I see. IMO, both solutions work. I don't have specific preferences
> here.
>
> The Sub-TLV style advertisement might align better with the traditional
> IGP/BGP aggregate approach, while
> the separate advertisement approach aligns better with the mapping server.
>
>
>
> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
> Many thanks!
>
> Nat
>
>
>
> Many thanks!
> Nat
>
>
>
> On Tue, Mar 4, 2025 at 4:30 AM <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 <internet-dra...@ietf.org>
> Sent: Monday, March 3, 2025 5:18 PM
> To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>; Kamran Raza <
> skr...@cisco.com>; Ketan Talaulikar <ketant.i...@gmail.com>; Shraddha
> Hegde <shrad...@juniper.net>; Syed Raza <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
> To unsubscribe send an email to 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.
>
> ____________________________________________________________________________________________________________
> 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
