Hi Aijun,
Thanks for your comments.
Please see inline [PSF]
Regards,
PSF
------------------原始邮件------------------
发件人：AijunWang
收件人：'Christian Hopps';lsr@ietf.org;
日 期 ：2021年06月02日 11:51
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
Advertisement"
Hi, All:
Again, I support part of this draft be adopted.
The deployment of Flex-Algo should be separated from the SR-TE Policy. Then
the use-case 1, 3 in section 3 should be pulled out, this can keep the
original design principle of Flex-Algo.
Adjacency-SID will only be included in the data packet when the packets need
pass a TI-LFA path, which is described in case-2 of section 3.
[PSF] If I get your point, it is use-case 1 that should be pulled out. Since
use-case 3 is just the primary case with consensus.
[PSF] And, use-case 2 is related with TI-LFA path to a remote destination node.
As we know an adjacency segment can be contained in the TI-LFA path. So that an
algorithm specific TI-LFA path should also possibly contain algorithm related
adjacency-sid. Only in this way can this adjacence-sid can be protected by the
algorithm specific local repair path. Therefore, we also agree on use-case 2.
And, I saw there was contentions for the following paragraph in section 5:
"The endpoint of a link shared by multiple flex-algo plane can reserve
different queue resources for different algorithms locally, and
perform priority based queue scheduling and traffic shaping. This
algorithm related reserved information can be advertised to other
nodes in the network through some mechanism, therefore it has an
impact on the constraint based path calculation of the flex-algo
plane. How to allocate algorithm related resouce and advertise it in
the network is out the scope of this document."
Since Flex-Algo doesn't consider the resource reservation, then such
reservation information needs not be advertised out of the node itself for
Flex-algo calculation.
[PSF] Agree. Flex-algo itself doesn't consider the resource reservation during
constraint SPF computation.
[PSF] My means is that other computation engine (e.g, an SDN controller) can
possibly compute a TE path within the scope of specific flex-algo plane. This
document doesn't discuss this topic in detail, just mentions it as a use case
(i.e., use-case 1). This topic can refer to "algorithm constraints" in
https://datatracker.ietf.org/doc/draft-peng-pce-te-constraints/
The local behavior based on the flex-algo related Adjacency-SID can be
described if the authors prefer.
[PSF] Yes, they just help to describe the purpose of algorithm related adj-sid.
It is free for an implementation to organize its local table, forwarding
resource, based on algorithm directly or indirectly.
SR-TE and Flex-Algo both can achieve the same goal, we need not mix them
together.
[PSF] This opinion is actually related to use-case 1. I don't insist on my own
view that use-case 1, i.e., SR-TE path within flex-algo plane, is kept in this
document. We can discuss it in another documents.
Best Regards
Aijun Wang
China Telecom
-----Original Message-----
From: lsr-boun...@ietf.org <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
