Hi, As draft-ietf-pce-pcep-ls approaches working group last call (it's in the queue), I thought it would be good to look at this draft and see whether it might be ready for adoption.
In some senses, PCEP-LS for optical is the under-lying driver for PCEP-LS. That is, optical systems are less likely to have a BGP implementation than are packet systems, and so BGP-LS is less attractive. However, in writing the PCEP-LS specs, the work was (sensibly, in my opinion) split into generic, technology agnostic parts (draft-ietf-pce-pcep-ls), and the optical-specific pieces (this document). My review has focused on: - ensuring consistency with draft-ietf-pce-pcep-ls - making sure that the experiment is properly described as discussed in draft-bonica-gendispatch-exp - collecting nits In summary, while there are some very minor points that would need to be fixed as part of (or shortly after) adoption, I see nothing that would prevent adoption. The document is very clear and readable. So I would like to encourage the chairs to put this draft in the queue. Thanks, Adrian === = Documenting an experiment = draft-bonica-gendispatch-exp lists a number of things an experimental draft should cover, the first of which is "Explain why the specification is presented as Experimental and not for publication on the Standards Track." I think you can do this quite simply in the introduction by: OLD This document describes an experimental extension to PCEP-LS for use in optical networks, and explains how encodings defined in [I-D.ietf-pce-pcep-ls] can be used in optical network contexts. NEW This document describes extensions to PCEP-LS for use in optical networks, and explains how encodings defined in [I-D.ietf-pce-pcep- ls] can be used in optical network contexts. Because [I-D.ietf-pce- pcep-ls] is presented as an Experimental document, the extensions defined here are also experimental. END The remaining points can be handled by including a section modeled on 1.1 of draft-ietf-pce-pcep-ls. Something like... 1.1. Scope The procedures described in this document are experimental. The experiment builds on the experiment described in [I-D.ietf-pce-pcep- ls] and is intended to enable research on the usage of PCEP to populate the Link-State and TE Information from a PCC to the PCE in an optical network. For this purpose, this document extends the PCEP message, PCEP object, and PCEP TLVs defined in [I-D.ietf-pce- pcep-ls] by defining 11 new PCEP TLVs specifically for carrying information about optical networks. This experiment is an extension of the PCEP-LS experiment. Therefore, interaction with implementations that do not support the PCEP-LS extensions will be exactly as defined in [I-D.ietf-pce-pcep- ls]. Nodes that participate in the PCEP-LS experiment, but that do not support the TLVs defined in this document will not understand those TLVs and so will ignore them as specified in [RFC5440]. Thus, nodes that understand PCEP-LS but do not participate in this experiment will not be harmed, but including them in the network will reduce the value of this experiment. The experiment will end three years after the RFC is published. Note, however, that the experiment described in [I-D.ietf-pce-pcep- ls] is planned to last three years after that document is published as an RFC. This may mean that this experiment is curtailed if the core PCEP-LS experiment ends and is declared a failure. In consequence, it is very important that the observations of this experiment be fed into the results of the PCEP-LS experiment. At the conclusion of this experiment, the authors will attempt to determine how widely this specification has been implemented and deployed. When the results of implementation and deployment are available and posted as an Internet-Draft, and assuming that the results are positive, this document (or part thereof) will be updated and refined, and could be moved from Experimental to Standards Track. = Issues = Section 6.1 requests the creation of a new registry for PCEP-LS sub- TLVs. This is OK, but: - You might not want to cause the creation of a registry in this experiment. It would, for the same of the experiment, be OK to simply state the sub-TLV type values (perhaps noting that, if the experiment is successful, a follow-up document might ask for the creation of a registry). - You would need to give IANA more clear instructions about the possible values (not just the ones you want assigned in this document). - The PCEP TLV Type field is 2 octets. - What are the assignment policies? - Somewhere, you need to explain why it is safe to assign sub-TLV types from the range 0-255 without risking clashing with any BGP-LS sub-TLVs that may also be carried in the Node-Attributed TLV or Link-Attribute TLV. And why you do not assign 0. = Nits and Editorial = 7 front page authors will need to be reduced. It is best to do this before moving to adoption. It's up to the authors how they resolve that. --- I think Danielle probably has an employer now. --- Title s/Extension/Extensions/ --- Abstract OLD An existing experimental document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and Traffic Engineering (TE) Information. NEW Link-State (LS) and Traffic Engineering (TE) Information can also be carried in Path Computation Element Communication Protocol (PCEP) using extensions known as PCEP-LS. END --- 4. OLD All Objects/TLVs defined in [I-D.ietf-pce-pcep-ls] are applicable to optical networks. NEW All Messages, Objects, and TLVs defined in [I-D.ietf-pce-pcep-ls] are applicable to optical networks. END _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
