Skip to main content

The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA)
draft-ietf-pce-wson-rwa-ext-17

Yes

(Deborah Brungard)

No Objection

(Adam Roach)
(Alissa Cooper)
(Ignas Bagdonas)
(Martin Vigoureux)
(Terry Manderson)

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

Deborah Brungard Former IESG member
(was Discuss, Yes) Yes
Yes () Not sent

                            
Adam Roach Former IESG member
No Objection
No Objection (for -12) Not sent

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (2019-02-05 for -11) Sent
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 IESG member
No Objection
No Objection (for -11) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2019-02-04 for -11) Sent
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.
Ben Campbell Former IESG member
No Objection
No Objection (2019-02-05 for -11) Sent
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 IESG member
(was Discuss) No Objection
No Objection (2019-03-01 for -16) Sent for earlier
Thank you for resolving my DISCUSS points.
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -12) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -12) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-02-04 for -11) Sent
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 IESG member
No Objection
No Objection (2019-02-05 for -11) Sent
Thank you for the very helpful Section 3.
Suresh Krishnan Former IESG member
No Objection
No Objection (2019-02-06 for -11) Sent
I had concerns similar to those raised by Benjamin and I support his DISCUSS.
Terry Manderson Former IESG member
No Objection
No Objection (for -12) Not sent