[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-11 Thread Nat Kao
Hi, Bruno. Thanks for the reply. Please refer to the inline [Nat3]. On Thu, Mar 6, 2025 at 5:36 PM wrote: > Hi Nat, > > > > Thanks for your reply and clarifications. > > Please see inline [Bruno3] > > > > *From:* Nat Kao > *Sent:* Thursday, March 6, 2025 3:48 AM > > Hi, Bruno. > > Many thanks

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-07 Thread Robert Raszuk
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 re

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-06 Thread Robert Raszuk
HI, I would just highlight that this draft enhances the scalability of the control plane and data plane of SR-MPLS networks by introducing a new level of hierarchy/indirection. That is achieved by prefix and label aggregation by ABRs. On the other hand as there is no free lunch it removes the ato

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-06 Thread Robert Raszuk
Hi Bruno, Do you mean « UPA is not enough” or “Hint” is not enough. > > Assuming the later, we can’t force people to use UPA, plus IP aggregation > existed before UPA. > > But we can rephrase to first express the drawback of aggregation (loss of > individual reachability) and then refers to a solu

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-06 Thread bruno . decraene
Hi, From: Robert Raszuk Sent: Thursday, March 6, 2025 4:11 PM HI, I would just highlight that this draft enhances the scalability of the control plane and data plane of SR-MPLS networks by introducing a new level of hierarchy/indirection. That is achieved by prefix and label aggregation by AB

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-06 Thread bruno . decraene
Hi Robert, Please see inline [Bruno] From: Robert Raszuk Sent: Thursday, March 6, 2025 11:10 AM To: DECRAENE Bruno INNOV/NET Cc: SPRING WG ; draft-decraene-spring-sr-mpls-aggregation-segm...@ietf.org Hi, Question (previously it was more of an observation :). Draft says: If the same Aggr

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-06 Thread bruno . decraene
Hi Robert, Thanks for the review and comments. Please see inline [Bruno] From: Robert Raszuk Sent: Thursday, March 6, 2025 10:38 AM To: DECRAENE Bruno INNOV/NET Hi, Very nice ! But is there a reason why this approach would not work for vanilla LDP ? If ABRs can aggregate MPLS labels and gen

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-06 Thread Robert Raszuk
Hi, Very nice ! But is there a reason why this approach would not work for vanilla LDP ? If ABRs can aggregate MPLS labels and generate aggregate SID they could as well generate aggregate FECs. And we do have for years the ability to use LPM for MPLS too. Of course perhaps folks are moving away

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-06 Thread bruno . decraene
Hi Nat, Thanks for your reply and clarifications. Please see inline [Bruno3] From: Nat Kao Sent: Thursday, March 6, 2025 3:48 AM Hi, Bruno. Many thanks for the reply. Please refer to the inline[Nat2]: On Wed, Mar 5, 2025 at 10:45 PM mailto:bruno.decra...@orange.com>> wrote: Hi Nat, Thanks fo

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-05 Thread Nat Kao
Hi, Bruno. Many thanks for the reply. Please refer to the inline[Nat2]: On Wed, Mar 5, 2025 at 10:45 PM wrote: > Hi Nat, > Thanks for your reply. > > I have one clarification question. Please see inline [Bruno2] > > > > *From:* Nat Kao > *Sent:* Wednesday, March 5, 2025 4:53 AM > *To:* DECRAEN

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-05 Thread bruno . decraene
Hi Nat, Thanks for your reply. I have one clarification question. Please see inline [Bruno2] From: Nat Kao Sent: Wednesday, March 5, 2025 4:53 AM To: DECRAENE Bruno INNOV/NET Cc: SPRING WG ; draft-decraene-spring-sr-mpls-aggregation-segm...@ietf.org Subject: Re: [spring] draft-decraene-spring-s

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-04 Thread Nat Kao
Hi, Bruno. Thanks for the reply. Please refer to the inline [Nat]. On Tue, Mar 4, 2025 at 9:37 PM wrote: > Hi Nat, > > > > Thanks for your review and the very good questions. > > > > Please see inline [Bruno] > > > > *From:* Nat Kao > *Sent:* Tuesday, March 4, 2025 10:59 AM > *To:* DECRAENE Br

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-04 Thread bruno . decraene
Hi Nat, Thanks for your review and the very good questions. Please see inline [Bruno] From: Nat Kao Sent: Tuesday, March 4, 2025 10:59 AM To: DECRAENE Bruno INNOV/NET Cc: SPRING WG ; draft-decraene-spring-sr-mpls-aggregation-segm...@ietf.org Subject: Re: [spring] draft-decraene-spring-sr-mpls

[spring] Re: draft-decraene-spring-sr-mpls-aggregation-segment-00

2025-03-04 Thread Nat Kao
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 aggreg