Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

Sorry, the body of the message seems to be encrypted. Just resend it.

Hi Jie,

See in-line [PSF], for resource reservation topic.

Regards,
PSF
发件人：Dongjie(Jimmy)
收件人：Christian Hopps;lsr@ietf.org;
日 期 ：2021年05月28日 11:40
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"
Hi,
I don't support the adoption of this document.
It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its typical use case is to provide protection path with Flex-Algo constraints for Adj-SID of a particular Flex-Algo, which is described in the case 3 of section 3.
However, section 3 and section 5 shows that it also aims to introduce further changes to the usage and operation of Flex-Algo, which is to provide resource reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves further discussion and is not only related to the per Flex-Algo Adj-SID extension.
Here are some comments about this change to Flex-Algo:
1. Flex-Algo defines the constraints for path computation in a distributed manner, it is not for resource reservation.
[PSF] Not sure. If you look at it from a device point of view, that's OK. But if you look at it from the controller's point of view, the controller can centrally compute an SR-TE path in the flex-algo plane, and  maintain the resource reservation. This document actually introduce nothing to the distributed shortest path computation in the devices, instead, it is used for centralized traffic engineering path computation.

2. Reserving resources for each Flex-Algo on a link does not make sense. The correlation between Flex-Algo and the network links is based on administrative groups (color), and the color of the link may or may not be included in the Flex-Algo definition. To follow the color based link correlation, a more practical approach would be to use Flex-Algo with L2 bundle as defined in draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link and the L2 member link to a Flex-Algo, this avoids the extension for per-FlexAlgo resource reservation.
[PSF] To let each flex-algo monopolize its own link resources (here do you think resources per algo is introduced?) may have scalability issues. However, it is actually a possible way. Under this way, I really don't understand the difference between the draft draft-zhu-lsr-isis-sr-vtn-flexalgo you mentioned and draft-peng-lsr-flex-algo-l2bundles. IMO, draft-zhu-lsr-isis-sr-vtn-flexalgo repackaged a VTN concept on the basis of draft-peng-lsr-flex-algo-l2bundles. Both of them need further discussion in another thread and are not recommended to be expanded here.

3. The Flex-Algo link TE attributes are advertised using ASLA, the TE attributes are shared by all Flex-Algos which include the link according to the FAD, and based on previous discussion, it seems there is no intention to introduce per Flex-Algo ID link attributes.
[PSF] Extend IGP to advertise resources per algorithm is optional, and need more discussions. Other ways are possible, e.g, configuration.

Best regards,
Jie
> -----Original Message-----
> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, May 27, 2021 4:57 AM
> To: lsr@ietf.org
> Cc: chopps@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
>
>
> Hi Folks,
>
> This begins a 2 week WG Adoption Call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid
> /
>
> Please indicate your support or objections by June 9th, 2021
>
> Authors, please respond to the list indicating whether you are aware of any IPR
> that applies to this draft.
>
> Thanks,
> Acee and Chris.
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr