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

Hi Jimmy,

please see inline:

On 28/05/2021 05:39, Dongjie (Jimmy) wrote:
> 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.

personally, I consider use case 3 (per algo protected Adj SID) the main 
reason we need this draft.

I don't care much about the other use cases to be honest, but I see no 
reason why an implementation can not associate local resources on a per 
algo basis. Sure, algo is not in the packet, but there are various 
indirect ways of doing that. All local behavior.

> 
> 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.
> 
> 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.

"correlation between Flex-Algo and the network links is based on 
administrative groups" - that's one way of doing so. There are others.

> 
> 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.

that's right, but I see no direct relationship with the above.

Anyway, I'm not a big fun of IETF documents describing local behaviors 
which are not needed for interoperability, so keeping these things out 
of the draft would be fine with me.

thanks,
Peter

> 
> 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
> 
> 