Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

["Dongjie (Jimmy)" <[e-mail]>]

Hi Samuel,

Thanks for your reply. Please see further inline:

From: Samuel Sidor (ssidor) [mailto:[e-mail]]
Sent: Friday, February 18, 2022 7:27 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Mahendra Negi <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Combining responses for 1. and 2. as those are related:

Encoding of SID/ERO-subobject level was used, because of multiple reasons:

a)      We may need to signal SL, which is explicitly configured by user (not just computed by PCE) and in such case user can potentially mix SIDs with different algorithms (if user is accepting risk of loops or if user knows that it cannot happen for various reasons in that specific case).

[Jie] Do you mean using PCEP to signal a configured SID list which consists of SIDs with different algorithms? To avoid the risk of loop, normally user would prefer to configure either SID list with strict path, or SIDs with consistent algorithm. Even if it is known that there is no loop, different algorithms represent different requirements to the path, logically can a path built with different algorithms meet specific requirement?

Thus it would be helpful to describe the typical scenario(s) of configuring SIDs with different algorithms .


b)      Different algorithm ID != different algorithm. With flex-algo different ID can be used for identification of same algorithm (e.g. in different IGP domains). Mixing SIDs with different algorithm ID in such case is safe, but we would not be able to signal such path in PCEP.

[Jie] I agree in the inter-domain case, the same algorithm can be represented using different IDs, and SIDs associated with different algorithm IDs can be used to build an inter-domain path to meet certain requirement. I’d suggest to add some description about this case to the document, and it would be better to limit the usage of different algorithm IDs in the ERO to this inter-domain case only.


c)      Also related to explicit SL – in some cases, user may configure SL explicitly on headend. Headend may not be able to resolve complete SL, so it may not be sure if algorithm of all SIDs is same.

[Jie] Understood.

3. We defined new types in older version of this draft – see:
https://datatracker.ietf.org/doc/html/draft-tokar-pce-sid-algo-03#section-6.1
but there were multiple comments indicating that it is resulting in too many new types (we need to extend draft for Adjacency SIDs as well) and it would be hard to maintain it for future – e.g. for cases where new NAI types are added. With this change we would have to double number of NAI types. Any extension like this in the future would double it again.

[Jie] Thanks for the pointer, I understand the cost of introducing new NAI types. While comparing to the format of SID types in BGP SR Policy, there is a fixed algorithm field and a A Flag is used to indicate whether this field carries an algorithm value or not. Perhaps another approach is to update the format of the existing NAI types to include the algorithm field. This could also better align the NAI types in PCEP with the Segment types in BGP.

Thoughts?

Best regards,
Jie

4. Makes sense. We will align it.

Regards,
Samuel

From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, February 18, 2022 10:09 AM
To: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Mahendra Negi <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG, chairs,

I just read the latest version of this document. In general incorporating Algorithm into PCEP could be useful. While I have the below questions on this version and it would be helpful if they can be resolved before adoption.


1.      This document introduces the algorithm constraint in the LSPA object, which means the algorithm needs to be considered in the computation of the path. IMO this is important for computing a loop-free path. While the draft also says that the “the PCE MAY insert prefix SIDs with a different Algorithm in order to successfully compute a path.” Mixing SIDs with different algorithms in a path has the risk of loops. It is suggested that the document provides some analysis about such risk, and the example of scenarios where mixing SIDs with different algorithms is safe and desired.


2.      This is related to the first question. If the analysis shows that using SIDs with different algorithms in a path is not a good idea, then it would be unnecessary to carry the algorithm ID in SERO subobjects, instead carrying it as a path attribute would be enough.



3.      Assuming the answer to question 2 is YES, the SR-ERO and SRv6-ERO subobjects were defined with a fixed format (do not support sub-TLVs), this document introduces an additional optional field to those sub-objects, and use a new flag to indicate the existence of the new optional field. To my understanding this is not a usual approach for protocol extension. Usually a new Type needs to be defined for a new format. It would be necessary to understand the implication of using flags to indicate the modification to the format of an existing object.



4.      The term “SID Algorithm” in this document is different from that is used in the RFCs of SR/SRv6 IGP/BGP extensions, where it is called “SR-Algorithm”. Suggest to make them consistent.

Best regards,
Jie

From: Pce [mailto:[e-mail]] On Behalf Of Dhruv Dhody
Sent: Friday, February 18, 2022 12:08 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Mahendra Negi <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG,

A reminder to please respond to the WG adoption poll by Monday!

Please be more vocal. The silence makes it difficult to judge consensus.

Also, the IPR responses from Alex, Shuping, and Mahendra are missing still.

Thanks!
Dhruv & Julien

On Fri, Feb 4, 2022 at 10:44 PM Dhruv Dhody <[e-mail]<mailto:[e-mail]>> wrote:
Hi WG,

This email begins the WG adoption poll for draft-tokar-pce-sid-algo-05.

https://datatracker.ietf.org/doc/draft-tokar-pce-sid-algo/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list.

Please respond by Monday 21st Feb 2022.

Have a great weekend.

Thanks!
Dhruv & Julien