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-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
