Thanks Aijun, We are discussing updated version of the draft with other co-authors (mostly with updated Introduction section, comments from Marina and also adding small clarification about RRO object). I’ll send it here as well after finishing that discussion. It should solve 1) and 2) from your list bellow. I’ll discuss 3) with them as well, but I’m fine with adding “Overview” or “Overall Procedures Description” section.
For 4) – I prefer current approach, where format of PCEP objects/TLVs, which are introduced or extended are defined in dedicated sections and separated from operations – so same approach as was already used in RFCs, which this drafts is related to like RFC8664 or RFC9603 (see sections “Object Formats” and “Procedures”), but in a lot of other PCEP RFCs as well – e.g. RFC8745, RFC8934, RFC9059. Operations described in the drafts are often impacting multiple objects/TLVs (e.g. capability and object, which can be included only if capability is set) and then it is difficult to include it into proper sections – often resulting in duplicate statements. But I’ll keep chairs, co-authors and other WG members to express their preference. Thanks, Samuel From: Aijun Wang <wangai...@tsinghua.org.cn> Sent: Wednesday, December 18, 2024 7:16 AM To: Samuel Sidor (ssidor) <ssi...@cisco.com>; 'Dhruv Dhody' <d...@dhruvdhody.com>; pce@ietf.org Cc: 'pce-chairs' <pce-cha...@ietf.org>; draft-ietf-pce-sid-a...@ietf.org Subject: 答复: [Pce] WGLC for draft-ietf-pce-sid-algo-15 Hi, Samuel: From your responses to me and to Marina, I recommend the authors of draft to do the following updates: 1) Rewrite the section 1 “Introduction” part, to state clear the necessary of this document, and its applied scenarios. 2) As you suggested, “some details can be removed from introduction (e.g. pointer to specific RFCs)”. 3) Add one new segment before “section 3”, as, for example, the “Overall Procedures Description”?, let reader to know where(for example, in which PCEP message etc.) to encapsulate these newly defined objects. 4) Rewrite the section 4 “Operation”. As you said, “section 4 is explaining how to use them”, is it better to merge it together with section 3(it will be more easier to use when comparing with its original definition) After accomplishing the above updates, I think the document will be more readable. Best Regards Aijun Wang China Telecom 发件人: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com] 发送时间: 2024年12月17日 17:01 收件人: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>; 'Dhruv Dhody' <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org> 抄送: 'pce-chairs' <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>; draft-ietf-pce-sid-a...@ietf.org<mailto:draft-ietf-pce-sid-a...@ietf.org> 主题: RE: [Pce] WGLC for draft-ietf-pce-sid-algo-15 Hi Aijun, Please see inline <S>. Thanks, Samuel From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>> Sent: Tuesday, December 17, 2024 8:48 AM To: 'Dhruv Dhody' <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org> Cc: 'pce-chairs' <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>; draft-ietf-pce-sid-a...@ietf.org<mailto:draft-ietf-pce-sid-a...@ietf.org> Subject: 答复: [Pce] WGLC for draft-ietf-pce-sid-algo-15 Hi, All: I have review the document and has the following comments: Although I think the document has already defined the related extension for the information exchange between PCE and PCC, It’s bit harder for the reader to get the reason behind this. 1. For example, in the introduction part, one sentence say: “While this information is available on the PCE, there is no method of conveying this information to the headend router. “ From my POV, the headend router can get such information from the IGP protocol, why it is necessary to get such information from the PCE? <S> There may be multiple reasons, but one obvious example is inter-area path computed by PCE and there is high chance that headend will see only topology from local IGP instance. 2. And again, it says: ”In addition, in the case of multiple (redundant) PCEs, when the headend receives a path from the primary PCE, it needs to be able to report the complete path information - including the SR-Algorithm - to the backup PCE so that in HA scenarios” From my POV, why the multiple(redundant)PCEs can’t exchange such information themselves? <S> PCEs can exchange such information between themselves, but existing standard synchronization mechanisms like one defined in draft-ietf-pce-state-sync also relies on forwarding PCRpt messages, so same extension is still required anyway (and not all vendors implemented such extension). 3. And, for the following rest part of introduction section, there is no clear logic for the newly extended TLV and their purposes, or the remaining part doesn’t cover all the extensions that described in the following sections. <S> Can you point to specific parts of introduction section? What I can see in introduction: - Initial 2 sections talking about SR-algorithm in ERO - 1 section talking about SR-algorithm constraint - 1 section describing where definition and valid values of SR-algorithms can be found - 1 section talking about capabilities - 1 section talking again about SR-algorithm constraint (this can be potentially merged with previous statement talking about constraint) Where PCEP extensions described in the document are: - Section 3.1 – capabilities - Sections 3.2 and 3.3 - SR-algorithm in ERO - Section 3.4 – SR-algorithm constraint - Section 3.5 – New metric values required to provide parity with IGP metric types for Flex-algo But I agree that maybe some details can be removed from introduction (e.g. pointer to specific RFCs) and we can add more details about purpose. 4. And finally, I am wondering is there any other TLV/Sub-TLV that needs to be synchronized between the PCE/PCC to make the final optimal path can be calculated in each of them? The draft just enumerate them, but doesn’t’ explain whether it covers all of them. <S> Section 3 is describing PCEP extensions (enumerating them) and section 4 is explaining how to use them. Please check it. If you are referring to Flex-algo path-computation and TLVs/sub-TLVs used for advertising Flex-algo definition and its content, then those are learned from IGP/BGP-LS and used in the path-computation (out of scope of this document), but PCEP is used just for encoding computed path (and accumulated metric). Then, I suggest the authors revisit the introduction part of this document, and rewrite it to assure the reader the necessary of this document, and also its enough coverage. Maybe I miss something, if so, please forgive me. <S> At least my interpretation is that section is called “Introduction” because its main goal is set the context and not to provide summary of changes and how to use them, but I’ll think about re-phrasing it a bit. Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> [mailto:forwardingalgori...@ietf.org] 代表 Dhruv Dhody 发送时间: 2024年12月6日 3:02 收件人: pce@ietf.org<mailto:pce@ietf.org> 抄送: pce-chairs <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>; draft-ietf-pce-sid-a...@ietf.org<mailto:draft-ietf-pce-sid-a...@ietf.org> 主题: [Pce] WGLC for draft-ietf-pce-sid-algo-15 Hi WG, This email starts a 3-weeks working group last call for draft-ietf-pce-sid-algo-15. https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/ Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome. The WG LC will end on Friday 27 Dec 2024. A general reminder to the WG to be more vocal during the last-call/adoption. Thanks, Dhruv & Julien
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
