The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA)
RFC 8780
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
Alvaro Retana No Objection
I share Benjamin's concerns about the clarity of this document, and support his DISCUSS. I have added some related comments below (not overlapping with his, of Mirja's). (1) §4.2 (Wavelength Selection TLV): "The encoding of this TLV is specified as the Wavelength Selection Sub-TLV in Section 4.2.2 of [RFC7689]." It should be made clear that this document is requesting a new TLV-type code to be assigned (§8.2) for this TLV. IOW, rfc7689 just describes the value part of the TLV... (2) §4.3: s/MUST be able to specify a restriction/MUST specify a restriction I assume you really want the restriction signaled, and not just the ability to do it... (3) §4.3: "the PCE MUST have mechanisms to know the tunability restrictions" How can this be Normatively enforced? It seems to be that the MUST is out of place. s/MUST/must (4) §4.3: "the PCC MUST be able to apply additional constraints" This sounds like a requirement, which is immediately satisfied by the definition of the Wavelength Restriction Constraint TLV...so I think the MUST is out of place. s/MUST/must (5) §4.3.2: s/wavelength restriction TLV/Wavelength Restriction Constraint TLV (6) I think that these references should be Normative: rfc5440, rfc8253.
(Deborah Brungard; former steering group member) (was Discuss, Yes) Yes
(Adam Roach; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
Benjamin's DISCUSS is a superset of issues I spotted, so I am agreeing with it.
In Section 4.1:
. Wavelength Selection TLV (32 bits): See Section 4.2 for
details.
Is TLV value 32 bit or the whole TLV? (This is the same issue as raised by Benjamin)
In Section 4.3:
o Link Identifiers: Identifies each link ID for which restriction
is applied. The length is dependent on the link format and the Count
field.
Is the type field extensible?
See Section 4.3.1. for Link Identifier encoding and Section
4.3.2. for the Wavelength Restriction Field encoding, respectively.
8.5. New PCEP TLV: Optical Interface Class List TLV
As described in Section 4.3, a new PCEP TLV is defined to indicate
the optical interface class list. IANA is to allocate this new TLV
from the "PCEP TLV Type Indicators" subregistry
(http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators).
Value Description Reference
---------------------------------------------------------
TBD5 Optical Interface [This.I-D]
Class List
I don't see TBD5 referenced anywhere else in the document.
8.6. New PCEP TLV: Client Signal TLV
As described in Section 4.3, a new PCEP TLV is defined to indicate
the client signal information. IANA is to allocate this new TLV from
the "PCEP TLV Type Indicators" subregistry
(http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators).
Value Description Reference
---------------------------------------------------------
TBD6 Client Signal Information [This.I-D]
I don't see TBD6 referenced anywhere else in the document either.
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
I support Benjamin's DISCUSS (and thank him for saving me some typing :-) ) IDNits complains about some citations without matching references. Please check. The "authors" section does not match the first page. Should some of those be listed as "contributors"?
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thank you for resolving my DISCUSS points.
(Ignas Bagdonas; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
I had some similar concerns as Benjamin but I think he listed them all. I some more minor editorial comments to add: 1) sec 4.3: "an Error-value (Error-value=3) MUST be defined so that the PCE MUST send a PCErr message with a PCEP-ERROR Object. See Section 5.1 for the details." This doesn't really make sense as normative "MUST"; I propose to change to lower case "must". 2) sec 4.3: "This TLV MAY appear more than once to be able to specify multiple restrictions." How do you know how much restrictions will be there? Based on a length field in the base protocol? Please clarify in the draft! 3) sec 4.3.2: "Length (16 bits): It is the length in bytes of the entire label set field." What is meant by "label set field" here? Please clarify in the draft or align wording accordingly. 4) Error value 3 is missing in sec 8.8!
(Spencer Dawkins; former steering group member) No Objection
Thank you for the very helpful Section 3.
(Suresh Krishnan; former steering group member) No Objection
I had concerns similar to those raised by Benjamin and I support his DISCUSS.
(Terry Manderson; former steering group member) No Objection