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

Hi Peter,

Thanks for your reply. Please see inline:

> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Friday, May 28, 2021 4:10 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Christian Hopps
> <chopps@chopps.org>; lsr@ietf.org
> Subject: 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 share the similar opinion with you. 

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

If all of these are local behavior, IMO they do not need to be described in this draft. 

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

OK, my point is Flex-Algo uses link constraints (color, SRLG, bandwidth constraint, etc.) in the FAD to associate it with a set of links, rather than configuring the Flex-Algo ID explicitly on the links. 

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

Thanks for confirming that there is no intention to introduce per Flex-Algo ID link attributes. Taking this and the above item into consideration, I assume the current Flex-Algo model does not support per Flex-Algo ID based queue and bandwidth configuration on a link.

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

Agreed, removing those use cases and operation text which are not related to Flex-Algo interoperability would make this document simpler. 

Best regards,
Jie

> 
> 
> 
> 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-si
> d
> >> /
> >>
> >> 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
> >
> >