Hi, Gunter: Thanks for your review and suggestions! I have updated the document and will submit it together with responses to other experts' comments. Some detail replies are inline below.
Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Gunter Van de Velde via Datatracker 发送时间: 2024年8月22日 12:21 收件人: The IESG <i...@ietf.org> 抄送: draft-ietf-pce-pcep-extension-native...@ietf.org; pce-cha...@ietf.org; pce@ietf.org 主题: [Pce] Gunter Van de Velde's No Objection on draft-ietf-pce-pcep-extension-native-ip-34: (with COMMENT) Gunter Van de Velde has entered the following ballot position for draft-ietf-pce-pcep-extension-native-ip-34: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-pcep-extension-native-ip-34 ## Many thanks for writing this document. I found the text not easy to process, mostly due to the many many references used in the document. ## I support Roman's discuss that applies to -34 #GENERIC COMMENTS #================ ## idnits spits up few message #DETAILED COMMENTS #================= ##classified as [minor] and [major] 17 Abstract 18 19 This document defines the Path Computation Element Communication 20 Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) 21 based applications in Native IP networks. It describes the key 22 information that is transferred between the Path Computation Element 23 (PCE) and the Path Computation Clients (PCC) to accomplish the End- 24 to-End (E2E) traffic assurance in the Native IP network under PCE as 25 a central controller (PCECC). [minor] an alternate proposal for abstract easier to digest and read for people with less PCEP awareness. Please use or ignore as you find useful " This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support the computation of paths for native IP traffic. The proposed extensions enable a Path Computation Element (PCE) to calculate and manage paths for native IP networks, enhancing the capabilities of PCEP beyond traditional MPLS and GMPLS networks. By introducing new PCEP objects and procedures, this document allows for the efficient use of IP network resources and supports the deployment of traffic engineering in native IP environments. " 【WAJ】Have updated the document accordingly. 114 Generally, Multiprotocol Label Switching Traffic Engineering (MPLS- 115 TE) requires the corresponding network devices to support Resource 116 ReSerVation Protocol (RSVP)/Label Distribution Protocol (LDP) 117 protocols to ensure the End-to-End (E2E) traffic performance. But in [minor] should there be no reference to rsvp and ldp RFCs? 【WAJ】Added the reference. 199 N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): If set to 1 by a PCEP 200 speaker, it indicates that the PCEP speaker is capable of TE in a 201 Native IP network as specified in this document. The flag MUST be 202 set by both the PCC and PCE to support this extension. [minor] What about the folowing proposed textblob? " N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): When set to 1 by a PCEP speaker, this flag indicates that the PCEP speaker is capable of TE in a Native IP network, as specified in this document. Both the PCC and PCE MUST set this flag to support this extension. " 【WAJ】Yes, Thanks. 223 If one or both speakers (PCE and PCC) have not indicated support and 224 willingness to use the PCEP extensions for Native-IP, the PCEP 225 extensions for the Native-IP MUST NOT be used. If a Native-IP [major] earlier in the text i only saw the N flag, however this text seems to indicate two flags? (1) support for Native-IP and (2) willingness to use Native-IP Maybe i missunderstood how the willingness is signalled? 【WAJ】：Only one flag. Here the "willingness" to use is describing the situation that that the newly defined PCEP extension is used, but the negotiation of this capabilities is not agreed. I have simplified the description as the followings: "If one or both speakers(PCE and PCC) have not indicated the support for Native-IP, the PCEP extensions for the Native-IP MUST NOT be used. If a Native-IP operation is attempted when both speaker have not agreed on the OPEN messages, the receiver of the message MUST: 350 The error handling for missing CCI objects is as per [RFC9050]. 351 Furthermore, one, and only one, object among BPI, EPR or PPA object 352 MUST be present. [minor] Maybe this can be rewritten more normative? what about " Error handling for missing CCI objects MUST be performed as specified in [RFC9050]. Additionally, exactly one object among the BPI, EPR, or PPA objects MUST be present. " 【WAJ】Yes. It seems more brevity. Have updated the document accordingly. _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
