Hi Jon, Thanks for your review. See inline...
From: Pce [mailto:[email protected]] On Behalf Of Jonathan Hardwick Sent: 12 November 2017 12:04 To: [email protected] Cc: [email protected]; [email protected] Subject: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints Re-sending to the correct DL :) From: Jonathan Hardwick Sent: 12 November 2017 12:02 To: '[email protected]' <[email protected]<mailto:[email protected]>> Cc: '[email protected]' <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Shepherd's review of draft-ietf-pce-exp-codepoints Hi there I am the document shepherd for this draft. Please find my review of the draft below. Many thanks for writing this draft. It looks in good shape overall. There are just a few clarifications I would like to make before we forward it to the IESG for publication. Cheers Jon Abstract This sentence about new sub-registries is misleading - the allocation policy for new sub-registries is decided by the drafts that create the sub-registries and does not have to be IETF Review. I propose: OLD IANA established a new top-level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Review. NEW IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. END [[[Dhruv Dhody]]] Ack. Introduction OLD The Path Computation Element communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. NEW The Path Computation Element communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. END i.e. add reference to RFC 5440. [[[Dhruv Dhody]]] Ack. The second paragraph is superfluous - I suggest deleting: Further, in order to support use cases described in [RFC8051], [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. [[[Dhruv Dhody]]] Because of the comment for handling the unknown experimental objects for the stateful PCE messages, I think it is better to continue to keep this text. What do you think? Please apply the same comments I made for the abstract to the following text: OLD IANA established a new top- level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Review as described in [RFC8126]. NEW IANA established a top- level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object and TLV types. The allocation policy for each of these sub-registries is IETF Review. END [[[Dhruv Dhody]]] Ack. Suggested change for clarity: OLD With some recent advancement, there is an enhanced need to experiment with PCEP. NEW Recently, there have been rapid advancements in PCE technology, which has created an enhanced need to experiment with PCEP. END [[[Dhruv Dhody]]] Ack. Section 5 The following paragraph does not tell the whole story. A PCE that does not recognize an experimental PCEP object, will reject the entire PCEP message and send a PCE error message with Error- Type="Unknown Object" or "Not supported object" as described in [RFC5440]. If the P flag is clear in the object header, then the PCE MAY ignore the object instead of generating this error message. Also, you do not discuss what a PCC would do on receipt of a PCUdp or PCInitiate containing an unrecognised experimental object - it is inconsistent that you don't cover these cases. (FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. Section 6.2 says that a PCErr should be sent, but then it refers to section 7.3.3, which says that a PCRpt should be sent. Hmmm.) [[[Dhruv Dhody]]] Yes. How about I update to this - If the PCE does not understand or support an experimental object with the P flag set in the Object Header, in the Path Computation Request message (PCReq), the entire PCEP message is rejected and PCE responds with a PCErr message with Error-Type="Unknown Object" or "Not supported object" as described in [RFC5440]. Otherwise the object is ignored. In case of stateful PCE messages [RFC8231], the P flag is ignored and the unknown object handling is as per the stateful PCE extensions. And let's try to handle the inconsistency in RFC 8231 with an errata perhaps? And handle PCE-initiated during AUTH48? Also: s/PCE error message/PCErr message/ [[[Dhruv Dhody]]] Ack Section 7 Nit: add comma after "accidentally" [[[Dhruv Dhody]]] Ok Appendix A I think the text in this Appendix could be clearer. Here is my suggestion. OLD Based on the feedback from the WG, it was decided to focus only on the essentials in the scope of this documents. For others, Experiments can use a new experimental TLV/Object instead. NEW Based on feedback from the PCE WG, it was decided to allocate an Experimental code point range only in the message, object and TLV sub-registries. The justification for this decision is that, if an experiment finds that it wants to use a new code point in another PCEP sub-registry, it can implement the same function using a new experimental object or TLV instead. END [[[Dhruv Dhody]]] Updated Other Please update reference draft-ietf-pce-stateful-pce -> RFC 8231 Please update reference draft-ietf-pce-pce-initiated-lsp-10 -> draft-ietf-pce-pce-initiated-lsp-11 [[[Dhruv Dhody]]] Ack Diff: https://tools.ietf.org/rfcdiff?url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-pcep-exp-codepoints-03.txt&url1=https://www.ietf.org/id/draft-ietf-pce-pcep-exp-codepoints-02.txt Thanks for the review! Regards, Dhruv
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
