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). 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. 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. 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. 4. Makes sense. We will align it. Regards, Samuel From: Dongjie (Jimmy) <jie.d...@huawei.com> Sent: Friday, February 18, 2022 10:09 AM To: Dhruv Dhody <d...@dhruvdhody.com>; pce@ietf.org Cc: draft-tokar-pce-sid-a...@ietf.org; Mahendra Negi <mahen...@rtbrick.com> 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:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody Sent: Friday, February 18, 2022 12:08 PM To: pce@ietf.org<mailto:pce@ietf.org> Cc: draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; Mahendra Negi <mahen...@rtbrick.com<mailto:mahen...@rtbrick.com>> 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 <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> 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
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
