Hi Jie, Thanks for your comments. Please see inline <S>:
Regards, Samuel From: Dongjie (Jimmy) <jie.d...@huawei.com> Sent: Monday, February 21, 2022 4:45 PM To: Samuel Sidor (ssidor) <ssi...@cisco.com> Cc: draft-tokar-pce-sid-a...@ietf.org; Dhruv Dhody <d...@dhruvdhody.com>; pce@ietf.org; Mahendra Negi <mahen...@rtbrick.com> Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05 Hi Samuel, Thanks for your reply. Please see further inline: From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com] Sent: Friday, February 18, 2022 7:27 PM To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>> Cc: draft-tokar-pce-sid-a...@ietf.org<mailto:draft-tokar-pce-sid-a...@ietf.org>; Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org>; Mahendra Negi <mahen...@rtbrick.com<mailto:mahen...@rtbrick.com>> 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 . <S> In most of the cases, requirements == algo used, but there are cases, where it may not be possible. Some examples. · case b) bellow (inter-domain) · support for less capable nodes (e.g. some node/nodes without SSPF/Algo1 support, but user want to use SSPF SIDs wherever possible and where user knows that it is still safe to mix SIDs). Implementation (PCE/PCC) can have local policy (e.g. some configuration) to decide if potentially unsafe paths should be used or blocked. As soon as we have at least possible use case (even if it is corner case), it may be bad idea to block it on protocol level. I agree that it may be good to describe use cases above in the draft. 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. <S> I’m not sure if we can really have hard requirement for PCC or PCE to check it. E.g. in case of configured SID list on PCC - PCC may not have visibility to whole topology in case of inter-domain paths, so it may not be able to verify it. E.g. consider that user configured SID list like this: 1. Label 26000 (algo 128) 2. Label 26005 (algo 129) PCC can just blindly report such path to PCE even if it does not know if both SIDs are in same area/domain or not. If we will strictly say that it is not valid, then user configured path can result in breaking protocol level limitations. Same applies to PCE, which can be potentially used only as a proxy. 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? <S> In case of approach with fixed algorithm field – what is the benefit of always including algorithm field even if it is not used? Because PCEP implementation will have to support both formats of SR-ERO – with and without algorithm field anyway (backward compatibility with implementations with algo draft support), so if algorithm is not really specified, we will just increase size of encoded ERO with no added value. For approach with updating existing NAI types – yes, I think that it can be done, but: 1. At least for me, SID Algo logically does not belong into NAI – even based on name NAI is supposed to be used for Node or Adjacency identifiers – I’m not sure how algo is identifying node or adjacency here. 2. NAI is optional – it will be required to include NAI even if it is not really needed in specific cases 3. Draft would still have to update them one by one, so it will have similar problem as original version of this draft – limited/expensive extensibility. Best regards, Jie 4. Makes sense. We will align it. Regards, Samuel From: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>> Sent: Friday, February 18, 2022 10:09 AM To: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>; 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, 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
