PCEP Extension for WSON Routing and Wavelength Assignment
draft-ietf-pce-wson-rwa-ext-17

Note: This ballot was opened for revision 11 and is now closed.

Deborah Brungard (was Discuss, Yes) Yes

Ignas Bagdonas No Objection

(Ben Campbell) No Objection

Comment (2019-02-05 for -11)
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"?

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2019-02-05 for -11)
Thank you for the very helpful Section 3.

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-03-01 for -16)
Thank you for resolving my DISCUSS points.

Suresh Krishnan No Objection

Comment (2019-02-06 for -11)
I had concerns similar to those raised by Benjamin and I support his DISCUSS.

Mirja Kühlewind No Objection

Comment (2019-02-04 for -11)
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!

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2019-02-05 for -11)
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.

Alvaro Retana No Objection

Comment (2019-02-04 for -11)
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.

Adam Roach No Objection

Martin Vigoureux No Objection