Hi Peter, Thanks for your reply. Please see inline:
> -----Original Message----- > From: Peter Psenak [mailto:[email protected]] > Sent: Friday, May 28, 2021 4:10 PM > To: Dongjie (Jimmy) <[email protected]>; Christian Hopps > <[email protected]>; [email protected] > 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:[email protected]] On Behalf Of Christian Hopps > >> Sent: Thursday, May 27, 2021 4:57 AM > >> To: [email protected] > >> Cc: [email protected] > >> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
