Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Just small update: 01 version is posted now (It is addressing comments received during adoption poll, which I originally posted in in draft-sidor-pce-circuit-style-pcep-extensions-06). Thanks for all valuable comments and for supporting this draft. Regards Samuel From: Samuel Sidor (ssidor) Sent: Saturday, December 23, 2023 12:05 PM To: Dhruv Dhody ; pce-chairs Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org Subject: RE: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi PCE-chairs, I submitted version 00 (which is aligned with draft-sidor-pce-circuit-style-pcep-extensions-05) – it is waiting for chairs approval. I’ll upload 01 version with handled comments (from version 06) after approving submission of 00 version. (Sorry for delay – I’m on PTO, so my responses may be delayed). Thanks a lot, Samuel From: Dhruv Dhody mailto:d...@dhruvdhody.com>> Sent: Wednesday, December 20, 2023 12:58 PM To: pce@ietf.org<mailto:pce@ietf.org> Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org> Subject: Re: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi WG, The adoption call is concluded and we have a new WG I-D. Thanks to those who provided feedback and comments. Authors, Please post a -00 version with no content change. Please handle comments received in -01. Thanks! Dhruv & Julien On Fri, Dec 1, 2023 at 4:02 PM Dhruv Dhody mailto:d...@dhruvdhody.com>> wrote: Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien --- Begin Message --- Internet-Draft draft-ietf-pce-circuit-style-pcep-extensions-01.txt is now available. It is a work item of the Path Computation Element (PCE) WG of the IETF. Title: PCEP extensions for Circuit Style Policies Authors: Samuel Sidor Praveen Maheshwari Andrew Stone Luay Jalil Shuping Peng Name:draft-ietf-pce-circuit-style-pcep-extensions-01.txt Pages: 12 Dates: 2024-01-05 Abstract: This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) for Circuit Style Policies - Segment-Routing Policy designed to satisfy requirements for connection-oriented transport services. New TLV is introduced to control path recomputation and new flag to add ability to request path with strict hops only. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-style-pcep-extensions/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-01.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-circuit-style-pcep-extensions-01 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --- End Message --- ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi PCE-chairs, I submitted version 00 (which is aligned with draft-sidor-pce-circuit-style-pcep-extensions-05) – it is waiting for chairs approval. I’ll upload 01 version with handled comments (from version 06) after approving submission of 00 version. (Sorry for delay – I’m on PTO, so my responses may be delayed). Thanks a lot, Samuel From: Dhruv Dhody Sent: Wednesday, December 20, 2023 12:58 PM To: pce@ietf.org Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org Subject: Re: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi WG, The adoption call is concluded and we have a new WG I-D. Thanks to those who provided feedback and comments. Authors, Please post a -00 version with no content change. Please handle comments received in -01. Thanks! Dhruv & Julien On Fri, Dec 1, 2023 at 4:02 PM Dhruv Dhody mailto:d...@dhruvdhody.com>> wrote: Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi WG, The adoption call is concluded and we have a new WG I-D. Thanks to those who provided feedback and comments. Authors, Please post a -00 version with no content change. Please handle comments received in -01. Thanks! Dhruv & Julien On Fri, Dec 1, 2023 at 4:02 PM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for > draft-sidor-pce-circuit-style-pcep-extensions-05. > > > https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ > > 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 Friday 15th Dec 2023. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi,Sorry for being late. Yes, I support the new version too. SY,Boris 01.12.2023, 13:33, "Dhruv Dhody" :Hi WG,This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05.https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/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 Friday 15th Dec 2023.Please be more vocal during WG polls!Thanks!Dhruv & Julien,___Pce mailing listPce@ietf.orghttps://www.ietf.org/mailman/listinfo/pce___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Samuel, Thanks for your work! The new version looks great to me! Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065; Cc: d...@dhruvdhody.com ;draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;pce@ietf.org ; Date: 2023年12月15日 21:23 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Thanks Quan, Updated version 06 (which includes suggestions from Ran and from you) was submitted. Regards, Samuel From: xiong.q...@zte.com.cn Sent: Friday, December 15, 2023 10:57 AM To: Samuel Sidor (ssidor) Cc: d...@dhruvdhody.com; draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your work! Yes, I agree with you. It seems good to me with “PCEP extensions described in this document can be used with any Path Setup Type.” LOL. Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065;d...@dhruvdhody.com ; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;pce@ietf.org ; Date: 2023年12月15日 17:25 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, What about modifying that statement from: “PCEP extensions described in this document are applicable to all Path Setup Types.” To something like: “PCEP extensions described in this document are not restricted to any specific Path Setup Type.” Or “PCEP extensions described in this document can be used with any Path Setup Type.” That way we will not really say that it is applicable to all, but at the same time we will not block anybody from using it if required with any other setup type in the future? (I would still prefer not going into route of excluding/including specific setup types). Thanks a lot, Samuel From: xiong.q...@zte.com.cn Sent: Friday, December 15, 2023 7:09 AM To: Samuel Sidor (ssidor) Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; d...@dhruvdhody.com; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your detailed explanation! I am not sure either about the PCECC and BIER-TE. To me that I may recall, for example( maybe not right), the path-recomputation TLV is in the request message from PCC to PCE, but there is no request message in PCECC mode. And for BIER-TE, it may has no requirement for path recomputation. I agree that a lot of PCEP objects/TLVs which are defined generically. But It may be not appropriate to state that they are applicable to all Path Setup Types. The extensions can be used when it is required in any of path setup type. It looks both good to me if you keep or drop the sentence. Thanks! Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;d...@dhruvdhody.com ;pce@ietf.org ; Date: 2023年12月14日 18:16 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Guan, By any chance, do you know about some specific reason why we would have to block for example path-recomputation TLV for BIER-TE or PCECC? To me something like ability to block path re-computation on PCE for specific LSP is generic extension. Whether there is practical use for specific path setup type is different question, but we don’t need to block such extension because of that (we have a lot of PCEP objects/TLVs which are defined generically and just not usable for LSPs of specific setup type). I personally consider having explicit list of supported path-setup types as less future proof (that’s why I modified based on comment from Dhruv to all setup types as I considered it as cleaner solution). For Strict-path flag from section 3.1 – that is slightly more questionable, but in general we are again talking only about bringing up O flag from RP object from stateless messages (PCReq/PCRep) to stateful messages (PCRpt,PCUpd,PCinit). So something what was already supposed to be supported by all setup types. So is there really something what needs to be explicitly blocked? I can rather imagine explicitly defining behavior for specific setup type (like BIER-TE or PCECC) for any of those extensions if we can see added value in using it, but behavior is not clear (that can be still done after adoption and discussion with PCE WG or authors of RFCs/drafts introducing those setup types). Thanks, Samuel From: xiong.q...@zte.com.cn Sent: Thursday, December 14, 2023 10:22 AM To: Samuel Sidor (ssidor) Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; d...@dhruvdhody.com; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your quick reply! Yes, I agree with you. The extensions may be applicable for RSVP-TE,SR,SRv6,native IP
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi PCE WG, Support adoption as coauthor. The extensions provided in the document provide needed (interoperable) knobs to complete some use cases defined in the SPRING Circuit Style document. While the current goal is CS-SR, the encodings defined provide independent functionality that can be applicable to other use cases or used individually, including other path setup types thus is another useful tool in the toolbox. Thanks Andrew From: Dhruv Dhody Date: Friday, December 1, 2023 at 5:33 AM To: "pce@ietf.org" Cc: "draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org" Subject: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Resent-From: Resent-To: , , , , Resent-Date: Friday, December 1, 2023 at 5:33 AM CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/ http://draft-sidor-pce-circuit-style-pcep-extensions/<https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/> 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Thanks Quan, Updated version 06 (which includes suggestions from Ran and from you) was submitted. Regards, Samuel From: xiong.q...@zte.com.cn Sent: Friday, December 15, 2023 10:57 AM To: Samuel Sidor (ssidor) Cc: d...@dhruvdhody.com; draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your work! Yes, I agree with you. It seems good to me with “PCEP extensions described in this document can be used with any Path Setup Type.” LOL. Best Regards, Quan Original From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>> To: 熊泉00091065;d...@dhruvdhody.com mailto:d...@dhruvdhody.com>>; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org> mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;pce@ietf.org mailto:pce@ietf.org>>; Date: 2023年12月15日 17:25 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, What about modifying that statement from: “PCEP extensions described in this document are applicable to all Path Setup Types.” To something like: “PCEP extensions described in this document are not restricted to any specific Path Setup Type.” Or “PCEP extensions described in this document can be used with any Path Setup Type.” That way we will not really say that it is applicable to all, but at the same time we will not block anybody from using it if required with any other setup type in the future? (I would still prefer not going into route of excluding/including specific setup types). Thanks a lot, Samuel From: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> mailto:xiong.q...@zte.com.cn>> Sent: Friday, December 15, 2023 7:09 AM To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>> Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>; d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>; pce@ietf.org<mailto:pce@ietf.org> Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your detailed explanation! I am not sure either about the PCECC and BIER-TE. To me that I may recall, for example( maybe not right), the path-recomputation TLV is in the request message from PCC to PCE, but there is no request message in PCECC mode. And for BIER-TE, it may has no requirement for path recomputation. I agree that a lot of PCEP objects/TLVs which are defined generically. But It may be not appropriate to state that they are applicable to all Path Setup Types. The extensions can be used when it is required in any of path setup type. It looks both good to me if you keep or drop the sentence. Thanks! Best Regards, Quan Original From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>> To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org> mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;d...@dhruvdhody.com mailto:d...@dhruvdhody.com>>;pce@ietf.org mailto:pce@ietf.org>>; Date: 2023年12月14日 18:16 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Guan, By any chance, do you know about some specific reason why we would have to block for example path-recomputation TLV for BIER-TE or PCECC? To me something like ability to block path re-computation on PCE for specific LSP is generic extension. Whether there is practical use for specific path setup type is different question, but we don’t need to block such extension because of that (we have a lot of PCEP objects/TLVs which are defined generically and just not usable for LSPs of specific setup type). I personally consider having explicit list of supported path-setup types as less future proof (that’s why I modified based on comment from Dhruv to all setup types as I considered it as cleaner solution). For Strict-path flag from section 3.1 – that is slightly more questionable, but in general we are again talking only about bringing up O flag from RP object from stateless messages (PCReq/PCRep) to stateful messages (PCRpt,PCUpd,PCinit). So something what was already supposed to be supported by all setup types. So is there really something what needs to be explicitly blocked? I can rather imagine explicitly defining behavior for specific setup type (like BIER-TE or PCECC) for any of those extensions if we can see added value in using it, but behavior is not clear (that can be still done after adoption and discussion with PCE WG or authors of RFCs/drafts introducing those setup types). Thanks, Samuel From: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> mailto:xiong.q...@zte.com.cn>> Sent: Thursday, December 14, 2023
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi All, I support the adoption of this draft since it builds on existing PCEP signaling for co-routed bidir paths and introduces extensions specifically for circuit-style paths. Thanks, Ketan On Fri, Dec 1, 2023 at 4:03 PM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for > draft-sidor-pce-circuit-style-pcep-extensions-05. > > > https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ > > 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 Friday 15th Dec 2023. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Samuel, Thanks for your work! Yes, I agree with you. It seems good to me with “PCEP extensions described in this document can be used with any Path Setup Type.” LOL. Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065;d...@dhruvdhody.com ; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;pce@ietf.org ; Date: 2023年12月15日 17:25 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, What about modifying that statement from: “PCEP extensions described in this document are applicable to all Path Setup Types.” To something like: “PCEP extensions described in this document are not restricted to any specific Path Setup Type.” Or “PCEP extensions described in this document can be used with any Path Setup Type.” That way we will not really say that it is applicable to all, but at the same time we will not block anybody from using it if required with any other setup type in the future? (I would still prefer not going into route of excluding/including specific setup types). Thanks a lot, Samuel From: xiong.q...@zte.com.cn Sent: Friday, December 15, 2023 7:09 AM To: Samuel Sidor (ssidor) Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; d...@dhruvdhody.com; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your detailed explanation! I am not sure either about the PCECC and BIER-TE. To me that I may recall, for example( maybe not right), the path-recomputation TLV is in the request message from PCC to PCE, but there is no request message in PCECC mode. And for BIER-TE, it may has no requirement for path recomputation. I agree that a lot of PCEP objects/TLVs which are defined generically. But It may be not appropriate to state that they are applicable to all Path Setup Types. The extensions can be used when it is required in any of path setup type. It looks both good to me if you keep or drop the sentence. Thanks! Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;d...@dhruvdhody.com ;pce@ietf.org ; Date: 2023年12月14日 18:16 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Guan, By any chance, do you know about some specific reason why we would have to block for example path-recomputation TLV for BIER-TE or PCECC? To me something like ability to block path re-computation on PCE for specific LSP is generic extension. Whether there is practical use for specific path setup type is different question, but we don’t need to block such extension because of that (we have a lot of PCEP objects/TLVs which are defined generically and just not usable for LSPs of specific setup type). I personally consider having explicit list of supported path-setup types as less future proof (that’s why I modified based on comment from Dhruv to all setup types as I considered it as cleaner solution). For Strict-path flag from section 3.1 – that is slightly more questionable, but in general we are again talking only about bringing up O flag from RP object from stateless messages (PCReq/PCRep) to stateful messages (PCRpt,PCUpd,PCinit). So something what was already supposed to be supported by all setup types. So is there really something what needs to be explicitly blocked? I can rather imagine explicitly defining behavior for specific setup type (like BIER-TE or PCECC) for any of those extensions if we can see added value in using it, but behavior is not clear (that can be still done after adoption and discussion with PCE WG or authors of RFCs/drafts introducing those setup types). Thanks, Samuel From: xiong.q...@zte.com.cn Sent: Thursday, December 14, 2023 10:22 AM To: Samuel Sidor (ssidor) Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; d...@dhruvdhody.com; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your quick reply! Yes, I agree with you. The extensions may be applicable for RSVP-TE,SR,SRv6,native IP, but I am not sure about it with BIER-TE and PCECC. It works well for me to explicitly describe for each extension whether it is generic or applicable to specific setup type. Thanks for your work! Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;d...@dhruvdhody.com ;pce@ietf.org ; Date: 2023年12月14日 16:27 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, (sorry I sent it before finishing mail) Originally we listed explicitly only RSVP-TE and SR-TE and then we modified based on comments from Dhruv to all setup types (attached mail). Extensions covered in this draft were introduced to support required extensions for CS
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Quan, What about modifying that statement from: “PCEP extensions described in this document are applicable to all Path Setup Types.” To something like: “PCEP extensions described in this document are not restricted to any specific Path Setup Type.” Or “PCEP extensions described in this document can be used with any Path Setup Type.” That way we will not really say that it is applicable to all, but at the same time we will not block anybody from using it if required with any other setup type in the future? (I would still prefer not going into route of excluding/including specific setup types). Thanks a lot, Samuel From: xiong.q...@zte.com.cn Sent: Friday, December 15, 2023 7:09 AM To: Samuel Sidor (ssidor) Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; d...@dhruvdhody.com; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your detailed explanation! I am not sure either about the PCECC and BIER-TE. To me that I may recall, for example( maybe not right), the path-recomputation TLV is in the request message from PCC to PCE, but there is no request message in PCECC mode. And for BIER-TE, it may has no requirement for path recomputation. I agree that a lot of PCEP objects/TLVs which are defined generically. But It may be not appropriate to state that they are applicable to all Path Setup Types. The extensions can be used when it is required in any of path setup type. It looks both good to me if you keep or drop the sentence. Thanks! Best Regards, Quan Original From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>> To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org> mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;d...@dhruvdhody.com mailto:d...@dhruvdhody.com>>;pce@ietf.org mailto:pce@ietf.org>>; Date: 2023年12月14日 18:16 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Guan, By any chance, do you know about some specific reason why we would have to block for example path-recomputation TLV for BIER-TE or PCECC? To me something like ability to block path re-computation on PCE for specific LSP is generic extension. Whether there is practical use for specific path setup type is different question, but we don’t need to block such extension because of that (we have a lot of PCEP objects/TLVs which are defined generically and just not usable for LSPs of specific setup type). I personally consider having explicit list of supported path-setup types as less future proof (that’s why I modified based on comment from Dhruv to all setup types as I considered it as cleaner solution). For Strict-path flag from section 3.1 – that is slightly more questionable, but in general we are again talking only about bringing up O flag from RP object from stateless messages (PCReq/PCRep) to stateful messages (PCRpt,PCUpd,PCinit). So something what was already supposed to be supported by all setup types. So is there really something what needs to be explicitly blocked? I can rather imagine explicitly defining behavior for specific setup type (like BIER-TE or PCECC) for any of those extensions if we can see added value in using it, but behavior is not clear (that can be still done after adoption and discussion with PCE WG or authors of RFCs/drafts introducing those setup types). Thanks, Samuel From: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> mailto:xiong.q...@zte.com.cn>> Sent: Thursday, December 14, 2023 10:22 AM To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>> Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>; d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>; pce@ietf.org<mailto:pce@ietf.org> Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your quick reply! Yes, I agree with you. The extensions may be applicable for RSVP-TE,SR,SRv6,native IP, but I am not sure about it with BIER-TE and PCECC. It works well for me to explicitly describe for each extension whether it is generic or applicable to specific setup type. Thanks for your work! Best Regards, Quan Original From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>> To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org> mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;d...@dhruvdhody.com mailto:d...@dhruvdhody.com>>;pce@ietf.org mailto:pce@ietf.org>>; Date: 2023年12月14日 16:27 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, (sorry I sent it before finishing mail) Originally we listed explicitly only RSVP-T
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Samuel, Thanks for your detailed explanation! I am not sure either about the PCECC and BIER-TE. To me that I may recall, for example( maybe not right), the path-recomputation TLV is in the request message from PCC to PCE, but there is no request message in PCECC mode. And for BIER-TE, it may has no requirement for path recomputation. I agree that a lot of PCEP objects/TLVs which are defined generically. But It may be not appropriate to state that they are applicable to all Path Setup Types. The extensions can be used when it is required in any of path setup type. It looks both good to me if you keep or drop the sentence. Thanks! Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;d...@dhruvdhody.com ;pce@ietf.org ; Date: 2023年12月14日 18:16 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Guan, By any chance, do you know about some specific reason why we would have to block for example path-recomputation TLV for BIER-TE or PCECC? To me something like ability to block path re-computation on PCE for specific LSP is generic extension. Whether there is practical use for specific path setup type is different question, but we don’t need to block such extension because of that (we have a lot of PCEP objects/TLVs which are defined generically and just not usable for LSPs of specific setup type). I personally consider having explicit list of supported path-setup types as less future proof (that’s why I modified based on comment from Dhruv to all setup types as I considered it as cleaner solution). For Strict-path flag from section 3.1 – that is slightly more questionable, but in general we are again talking only about bringing up O flag from RP object from stateless messages (PCReq/PCRep) to stateful messages (PCRpt,PCUpd,PCinit). So something what was already supposed to be supported by all setup types. So is there really something what needs to be explicitly blocked? I can rather imagine explicitly defining behavior for specific setup type (like BIER-TE or PCECC) for any of those extensions if we can see added value in using it, but behavior is not clear (that can be still done after adoption and discussion with PCE WG or authors of RFCs/drafts introducing those setup types). Thanks, Samuel From: xiong.q...@zte.com.cn Sent: Thursday, December 14, 2023 10:22 AM To: Samuel Sidor (ssidor) Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; d...@dhruvdhody.com; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your quick reply! Yes, I agree with you. The extensions may be applicable for RSVP-TE,SR,SRv6,native IP, but I am not sure about it with BIER-TE and PCECC. It works well for me to explicitly describe for each extension whether it is generic or applicable to specific setup type. Thanks for your work! Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;d...@dhruvdhody.com ;pce@ietf.org ; Date: 2023年12月14日 16:27 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, (sorry I sent it before finishing mail) Originally we listed explicitly only RSVP-TE and SR-TE and then we modified based on comments from Dhruv to all setup types (attached mail). Extensions covered in this draft were introduced to support required extensions for CS policies, but at least some of those extensions (if specific section is not describing something else) is potentially applicable to other setup types. E.g. extensions from section 3.2 for blocking re-computation. We can still drop that specific statement and explicitly describe for each extension whether it is generic or applicable to specific setup type only. Would that work for you? Thanks, Samuel From: Samuel Sidor (ssidor) Sent: Thursday, December 14, 2023 9:24 AM To: xiong.q...@zte.com.cn; d...@dhruvdhody.com Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, Originally we explicitly listed From: Pce On Behalf Of xiong.q...@zte.com.cn Sent: Thursday, December 14, 2023 7:53 AM To: d...@dhruvdhody.com Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Dhruv, I support the adoption of this draft. Thanks for the work from authors. But I am confused about section 1 "PCEP extensions described in this document are applicable to all Path Setup Types". This draft mainly focus on the Circuit Style Policies and SR policy but path setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path and the newly adopted
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Samuel, Thanks a lot for your updates. Agree with all changes. Best Regards, Ran Original From: SamuelSidor(ssidor) To: 陈然00080434; Cc: d...@dhruvdhody.com ;pce@ietf.org ;draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ; Date: 2023年12月14日 23:33 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Ran, Adding updated version of the draft. I can submit tomorrow if there are no other comments (there is also discussion with Quan about path setup types supported in that draft, but there is no conclusion yet, so that change is not included yet). Regards, Samuel From: chen@zte.com.cn Sent: Thursday, December 14, 2023 10:55 AM To: Samuel Sidor (ssidor) Cc: d...@dhruvdhody.com; pce@ietf.org; draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks a lot for your responses. It looks good. Best Regards, Ran Original From: SamuelSidor(ssidor) To: 陈然00080434; Cc: d...@dhruvdhody.com ;pce@ietf.org ;draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ; Date: 2023年12月14日 16:51 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Ran, Thanks for your comments. Correct, we are just introducing new flag in existing TLV. Original title seems to be aligned with other drafts introducing new flags in that TLV, e.g.: https://datatracker.ietf.org/doc/html/draft-peng-pce-entropy-label-position-10#name-the-lsp-extended-flag-tlv but I can still rename it to follow your suggestion and it seems to be more accurate (“New Flag in the LSP-EXTENDED-FLAGS TLV”). For “Type” and “Length” fields – those are based on older draft version of RFC9357 (https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-extended-flags-07 ). The plan was to introduce TLV format after assigning IANA codepoint for new flag allocated and as part of TLV format, we are usually describing content of individual fields in that TLV (including type and length). I can drop them for now, since codepoints were not allocated and TLV format is not included. For “E-flag” – I agree, I can drop it as it does not make sense to list all flags already allocated in that TLV. Originally we mentioned that draft only to explicitly indicate that there are other drafts, which are trying to allocate fields in that TLV. Regards, Samuel From: chen@zte.com.cn Sent: Thursday, December 14, 2023 8:59 AM To: d...@dhruvdhody.com; pce@ietf.org; draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi WG I surport the adoption of this draft, it is very useful. but I have a few minor (non-blocking) comments: 3.1. LSP-EXTENDED-FLAG TLV The LSP object is defined in Section 7.3 of [RFC8231], and the new extended flags TLV is defined in [RFC9357]. This draft reuse the new extended flags TLV is defined in [RFC9357], and only defines a new flag,right? If so, it is recommended that the title be changed to "New Flag in the LSP-EXTENDED-FLAGS TLV" which is more appropriate. I am confused when I see the description below in the draft: In addition, Not only [I-D.peng-pce-entropy-label-position] has defined the E-flag, IANA has already assigned multiple LSP-EXTENDED-FLAG TLV Flag Field , see link: https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended-flag-tlv-flags. It is recommended to delete the description of E-flag. Best Regards, Ran Original From: DhruvDhody To: pce@ietf.org ; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ; Date: 2023年12月01日 18:33 Subject: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Guan, By any chance, do you know about some specific reason why we would have to block for example path-recomputation TLV for BIER-TE or PCECC? To me something like ability to block path re-computation on PCE for specific LSP is generic extension. Whether there is practical use for specific path setup type is different question, but we don’t need to block such extension because of that (we have a lot of PCEP objects/TLVs which are defined generically and just not usable for LSPs of specific setup type). I personally consider having explicit list of supported path-setup types as less future proof (that’s why I modified based on comment from Dhruv to all setup types as I considered it as cleaner solution). For Strict-path flag from section 3.1 – that is slightly more questionable, but in general we are again talking only about bringing up O flag from RP object from stateless messages (PCReq/PCRep) to stateful messages (PCRpt,PCUpd,PCinit). So something what was already supposed to be supported by all setup types. So is there really something what needs to be explicitly blocked? I can rather imagine explicitly defining behavior for specific setup type (like BIER-TE or PCECC) for any of those extensions if we can see added value in using it, but behavior is not clear (that can be still done after adoption and discussion with PCE WG or authors of RFCs/drafts introducing those setup types). Thanks, Samuel From: xiong.q...@zte.com.cn Sent: Thursday, December 14, 2023 10:22 AM To: Samuel Sidor (ssidor) Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; d...@dhruvdhody.com; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Samuel, Thanks for your quick reply! Yes, I agree with you. The extensions may be applicable for RSVP-TE,SR,SRv6,native IP, but I am not sure about it with BIER-TE and PCECC. It works well for me to explicitly describe for each extension whether it is generic or applicable to specific setup type. Thanks for your work! Best Regards, Quan Original From: SamuelSidor(ssidor) mailto:ssi...@cisco.com>> To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org> mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>;d...@dhruvdhody.com mailto:d...@dhruvdhody.com>>;pce@ietf.org mailto:pce@ietf.org>>; Date: 2023年12月14日 16:27 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, (sorry I sent it before finishing mail) Originally we listed explicitly only RSVP-TE and SR-TE and then we modified based on comments from Dhruv to all setup types (attached mail). Extensions covered in this draft were introduced to support required extensions for CS policies, but at least some of those extensions (if specific section is not describing something else) is potentially applicable to other setup types. E.g. extensions from section 3.2 for blocking re-computation. We can still drop that specific statement and explicitly describe for each extension whether it is generic or applicable to specific setup type only. Would that work for you? Thanks, Samuel From: Samuel Sidor (ssidor) Sent: Thursday, December 14, 2023 9:24 AM To: xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn>; d...@dhruvdhody.com<mailto:d...@dhruvdhody.com> Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>; pce@ietf.org<mailto:pce@ietf.org> Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, Originally we explicitly listed From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> Sent: Thursday, December 14, 2023 7:53 AM To: d...@dhruvdhody.com<mailto:d...@dhruvdhody.com> Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>; pce@ietf.org<mailto:pce@ietf.org> Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Dhruv, I support the adoption of this draft. Thanks for the work from authors. But I am confused about section 1 "PCEP extensions described in this document are applicable to all Path Setup Types". This draft mainly focus on the Circuit Style Policies and SR policy but path setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path and the newly adopted BIER-TE. I suggest that it is better to provide clarification about other path setup types or remove this sentence. Thanks, Quan <https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/Should this draft be adopted by the PCE <___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Samuel, Thanks a lot for your responses. It looks good. Best Regards, Ran Original From: SamuelSidor(ssidor) To: 陈然00080434; Cc: d...@dhruvdhody.com ;pce@ietf.org ;draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ; Date: 2023年12月14日 16:51 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Ran, Thanks for your comments. Correct, we are just introducing new flag in existing TLV. Original title seems to be aligned with other drafts introducing new flags in that TLV, e.g.: https://datatracker.ietf.org/doc/html/draft-peng-pce-entropy-label-position-10#name-the-lsp-extended-flag-tlv but I can still rename it to follow your suggestion and it seems to be more accurate (“New Flag in the LSP-EXTENDED-FLAGS TLV”). For “Type” and “Length” fields – those are based on older draft version of RFC9357 (https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-extended-flags-07 ). The plan was to introduce TLV format after assigning IANA codepoint for new flag allocated and as part of TLV format, we are usually describing content of individual fields in that TLV (including type and length). I can drop them for now, since codepoints were not allocated and TLV format is not included. For “E-flag” – I agree, I can drop it as it does not make sense to list all flags already allocated in that TLV. Originally we mentioned that draft only to explicitly indicate that there are other drafts, which are trying to allocate fields in that TLV. Regards, Samuel From: chen@zte.com.cn Sent: Thursday, December 14, 2023 8:59 AM To: d...@dhruvdhody.com; pce@ietf.org; draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi WG I surport the adoption of this draft, it is very useful. but I have a few minor (non-blocking) comments: 3.1. LSP-EXTENDED-FLAG TLV The LSP object is defined in Section 7.3 of [RFC8231], and the new extended flags TLV is defined in [RFC9357]. This draft reuse the new extended flags TLV is defined in [RFC9357], and only defines a new flag,right? If so, it is recommended that the title be changed to "New Flag in the LSP-EXTENDED-FLAGS TLV" which is more appropriate. I am confused when I see the description below in the draft: In addition, Not only [I-D.peng-pce-entropy-label-position] has defined the E-flag, IANA has already assigned multiple LSP-EXTENDED-FLAG TLV Flag Field , see link: https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended-flag-tlv-flags. It is recommended to delete the description of E-flag. Best Regards, Ran Original From: DhruvDhody To: pce@ietf.org ; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ; Date: 2023年12月01日 18:33 Subject: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Samuel, Thanks for your quick reply! Yes, I agree with you. The extensions may be applicable for RSVP-TE,SR,SRv6,native IP, but I am not sure about it with BIER-TE and PCECC. It works well for me to explicitly describe for each extension whether it is generic or applicable to specific setup type. Thanks for your work! Best Regards, Quan Original From: SamuelSidor(ssidor) To: 熊泉00091065; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ;d...@dhruvdhody.com ;pce@ietf.org ; Date: 2023年12月14日 16:27 Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, (sorry I sent it before finishing mail) Originally we listed explicitly only RSVP-TE and SR-TE and then we modified based on comments from Dhruv to all setup types (attached mail). Extensions covered in this draft were introduced to support required extensions for CS policies, but at least some of those extensions (if specific section is not describing something else) is potentially applicable to other setup types. E.g. extensions from section 3.2 for blocking re-computation. We can still drop that specific statement and explicitly describe for each extension whether it is generic or applicable to specific setup type only. Would that work for you? Thanks, Samuel From: Samuel Sidor (ssidor) Sent: Thursday, December 14, 2023 9:24 AM To: xiong.q...@zte.com.cn; d...@dhruvdhody.com Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, Originally we explicitly listed From: Pce On Behalf Of xiong.q...@zte.com.cn Sent: Thursday, December 14, 2023 7:53 AM To: d...@dhruvdhody.com Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Dhruv, I support the adoption of this draft. Thanks for the work from authors. But I am confused about section 1 "PCEP extensions described in this document are applicable to all Path Setup Types". This draft mainly focus on the Circuit Style Policies and SR policy but path setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path and the newly adopted BIER-TE. I suggest that it is better to provide clarification about other path setup types or remove this sentence. Thanks, Quan <https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/Should this draft be adopted by the PCE <___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Ran, Thanks for your comments. Correct, we are just introducing new flag in existing TLV. Original title seems to be aligned with other drafts introducing new flags in that TLV, e.g.: https://datatracker.ietf.org/doc/html/draft-peng-pce-entropy-label-position-10#name-the-lsp-extended-flag-tlv but I can still rename it to follow your suggestion and it seems to be more accurate (“New Flag in the LSP-EXTENDED-FLAGS TLV”). For “Type” and “Length” fields – those are based on older draft version of RFC9357 (https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-extended-flags-07 ). The plan was to introduce TLV format after assigning IANA codepoint for new flag allocated and as part of TLV format, we are usually describing content of individual fields in that TLV (including type and length). I can drop them for now, since codepoints were not allocated and TLV format is not included. For “E-flag” – I agree, I can drop it as it does not make sense to list all flags already allocated in that TLV. Originally we mentioned that draft only to explicitly indicate that there are other drafts, which are trying to allocate fields in that TLV. Regards, Samuel From: chen@zte.com.cn Sent: Thursday, December 14, 2023 8:59 AM To: d...@dhruvdhody.com; pce@ietf.org; draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi WG I surport the adoption of this draft, it is very useful. but I have a few minor (non-blocking) comments: 3.1. LSP-EXTENDED-FLAG TLV The LSP object is defined in Section 7.3 of [RFC8231], and the new extended flags TLV is defined in [RFC9357]. This draft reuse the new extended flags TLV is defined in [RFC9357], and only defines a new flag,right? If so, it is recommended that the title be changed to "New Flag in the LSP-EXTENDED-FLAGS TLV" which is more appropriate. I am confused when I see the description below in the draft: [cid:image001.png@01DA2E70.4A875950] In addition, Not only [I-D.peng-pce-entropy-label-position] has defined the E-flag, IANA has already assigned multiple LSP-EXTENDED-FLAG TLV Flag Field , see link: https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended-flag-tlv-flags. It is recommended to delete the description of E-flag. Best Regards, Ran Original From: DhruvDhody mailto:d...@dhruvdhody.com>> To: pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org> mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>>; Date: 2023年12月01日 18:33 Subject: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 ___ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Quan, (sorry I sent it before finishing mail) Originally we listed explicitly only RSVP-TE and SR-TE and then we modified based on comments from Dhruv to all setup types (attached mail). Extensions covered in this draft were introduced to support required extensions for CS policies, but at least some of those extensions (if specific section is not describing something else) is potentially applicable to other setup types. E.g. extensions from section 3.2 for blocking re-computation. We can still drop that specific statement and explicitly describe for each extension whether it is generic or applicable to specific setup type only. Would that work for you? Thanks, Samuel From: Samuel Sidor (ssidor) Sent: Thursday, December 14, 2023 9:24 AM To: xiong.q...@zte.com.cn; d...@dhruvdhody.com Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org Subject: RE: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Quan, Originally we explicitly listed From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of xiong.q...@zte.com.cn<mailto:xiong.q...@zte.com.cn> Sent: Thursday, December 14, 2023 7:53 AM To: d...@dhruvdhody.com<mailto:d...@dhruvdhody.com> Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org<mailto:draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org>; pce@ietf.org<mailto:pce@ietf.org> Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Dhruv, I support the adoption of this draft. Thanks for the work from authors. But I am confused about section 1 "PCEP extensions described in this document are applicable to all Path Setup Types". This draft mainly focus on the Circuit Style Policies and SR policy but path setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path and the newly adopted BIER-TE. I suggest that it is better to provide clarification about other path setup types or remove this sentence. Thanks, Quan <https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/Should this draft be adopted by the PCE <--- Begin Message --- Hi, Can you please upload a new version of the I-D that tidies up the document in preparation for WG adoption call? - Limit the number of authors to 5 - Add text to the security consideration section (add references to relevant rfcs if no new security threat is assumed) - Think about adding a mangebility consideration - Instead of saying that the applicability to RSVP-TE and SR-TE better yet say it is applicable to all path setup types! - I am confused by - "For example Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if there is only one adjacency). the PCE MUST use Adjacency SIDs only."; are Adj SID "MAY" or "MUST"?? It should be MUST right? - What is the way to indicate that a computed path no longer meets the original constraints when the recomputation is blocked? Isn't that something that is useful for operators to know? - When the P flag is cleared or the TLV is not present, we fall back to the existing scenario and in which one would assume PCE does the recomputation based on various triggers yet the draft uses "MAY recompute"... could this be a "SHOULD"? - Add implementation Status if you have plans of implementations! Thanks! Dhruv --- End Message --- ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Quan, Originally we explicitly listed From: Pce On Behalf Of xiong.q...@zte.com.cn Sent: Thursday, December 14, 2023 7:53 AM To: d...@dhruvdhody.com Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi Dhruv, I support the adoption of this draft. Thanks for the work from authors. But I am confused about section 1 "PCEP extensions described in this document are applicable to all Path Setup Types". This draft mainly focus on the Circuit Style Policies and SR policy but path setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path and the newly adopted BIER-TE. I suggest that it is better to provide clarification about other path setup types or remove this sentence. Thanks, Quan <https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/Should this draft be adopted by the PCE <--- Begin Message --- Hi, Can you please upload a new version of the I-D that tidies up the document in preparation for WG adoption call? - Limit the number of authors to 5 - Add text to the security consideration section (add references to relevant rfcs if no new security threat is assumed) - Think about adding a mangebility consideration - Instead of saying that the applicability to RSVP-TE and SR-TE better yet say it is applicable to all path setup types! - I am confused by - "For example Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if there is only one adjacency). the PCE MUST use Adjacency SIDs only."; are Adj SID "MAY" or "MUST"?? It should be MUST right? - What is the way to indicate that a computed path no longer meets the original constraints when the recomputation is blocked? Isn't that something that is useful for operators to know? - When the P flag is cleared or the TLV is not present, we fall back to the existing scenario and in which one would assume PCE does the recomputation based on various triggers yet the draft uses "MAY recompute"... could this be a "SHOULD"? - Add implementation Status if you have plans of implementations! Thanks! Dhruv --- End Message --- ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi WG I surport the adoption of this draft, it is very useful. but I have a few minor (non-blocking) comments: 3.1. LSP-EXTENDED-FLAG TLV The LSP object is defined in Section 7.3 of [RFC8231], and the new extended flags TLV is defined in [RFC9357]. This draft reuse the new extended flags TLV is defined in [RFC9357], and only defines a new flag,right? If so, it is recommended that the title be changed to "New Flag in the LSP-EXTENDED-FLAGS TLV" which is more appropriate. I am confused when I see the description below in the draft: In addition, Not only [I-D.peng-pce-entropy-label-position] has defined the E-flag, IANA has already assigned multiple LSP-EXTENDED-FLAG TLV Flag Field , see link: https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended-flag-tlv-flags. It is recommended to delete the description of E-flag. Best Regards, Ran Original From: DhruvDhody To: pce@ietf.org ; Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org ; Date: 2023年12月01日 18:33 Subject: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Dhruv, I support the adoption of this draft. Thanks for the work from authors. But I am confused about section 1 "PCEP extensions described in this document are applicable to all Path Setup Types". This draft mainly focus on the Circuit Style Policies and SR policy but path setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path and the newly adopted BIER-TE. I suggest that it is better to provide clarification about other path setup types or remove this sentence. Thanks, Quan
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi, I support the adoption of this work as a coauthor. It provides the PCEP extensions for enabling the CS SR Policy currently being specified in SPRING. Thank you! Best Regards, Shuping From: Christian Schmutzer (cschmutz) [mailto:cschm...@cisco.com] Sent: Thursday, December 14, 2023 5:58 AM To: Dhruv Dhody Cc: Christian Schmutzer (cschmutz) ; pce@ietf.org; draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org Subject: Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 I support the adoption of this draft as it defines the essential PCEP extensions need for the concepts described in draft-ietf-spring-cs-sr-policy. regards Christian On 01.12.2023, at 05:32, Dhruv Dhody mailto:d...@dhruvdhody.com>> wrote: Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
I support the adoption of this draft as it defines the essential PCEP extensions need for the concepts described in draft-ietf-spring-cs-sr-policy. regards Christian On 01.12.2023, at 05:32, Dhruv Dhody wrote: Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
I support the adoption of pcep extension to support circuit style sr policy. I don’t see any issues with the draft that need to be fixed and I am willing to work on the draft. Thanks <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* On Fri, Dec 1, 2023 at 5:33 AM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for > draft-sidor-pce-circuit-style-pcep-extensions-05. > > > https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ > > 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 Friday 15th Dec 2023. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi, As contributor, I will support the adoption. Reza From: Dhruv Dhody Sent: Friday, December 1, 2023 11:33 AM To: pce@ietf.org Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org Subject: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/__;!!OSsGDw!JFHDI7A0GQl3GCBo3Q0QPZ-JQS1hXm-Mcnc6xpP6M2d8wmgvTtXWbgPVbNAR7J4DEdc5zrQsCA$> 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi WG, I support adoption of this draft (co-author). It provides useful extensions to PCEP for Circuit style policies, but those changes are potentially re-usable for other use cases, There is draft in spring, which is defining CS policy and it was adopted already: https://datatracker.ietf.org/doc/draft-ietf-spring-cs-sr-policy/ and changes in PCEP draft are needed to fully support it. To comment “What needs to be fixed before or after adoption?” – just to keep WG informed – we (co-authors) plan to add capability advertisement after adoption. Thanks a lot, Samuel From: Dhruv Dhody Sent: Friday, December 1, 2023 11:33 AM To: pce@ietf.org Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org Subject: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05 Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Hi WG, This email begins the WG adoption poll for draft-sidor-pce-circuit-style-pcep-extensions-05. https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ 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 Friday 15th Dec 2023. Please be more vocal during WG polls! Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
