Telechat Review of draft-ietf-ccamp-wson-signal-compatibility-ospf-15
review-ietf-ccamp-wson-signal-compatibility-ospf-15-opsdir-telechat-brownlee-2015-08-06-00

Hi all:

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
operational area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This draft's Expiry Date is November 2014.  It's generally clear
in what it says, and it's certainly useful.  However, I feel that
there are a few aspects that could  be made a little clearer for
implementors.


Abstract:
  "This document provides Generalized Multiprotocol Label Switching
   (GMPLS) Open Shortest Path First (OSPF) routing enhancements to
   support signal compatibility constraints associated with
   Wavelength- Switched Optical network (WSON) elements. These routing
   enhancements are applicable in common optical or hybrid
   electro-optical networks where not all of the optical signals in
   the network are compatible with all network elements participating
   in the network.

   This compatibility constraint model is applicable to common optical
   or hybrid electro optical systems such as
   Optical-Electronic-Optical (OEO) switches, regenerators, and
   wavelength converters since such systems can be limited to
   processing only certain types of WSON signals."

The Introduction mentions WSON-Encode and GEN-OSPF; these are Normative
references, presumably to Drafts that will eventually be Standards
Track RFCs?  This comment also applies to GEN-Encode in section 3.

Section 2 defines values for sub-TLVs of the Optical Node Property
TLV.  Their values are all shown as TBA; using something like TBA1,
TBA2, .. TBA5 would make it clearer to IANA that they're different
values.

Also in section 2, you have sub-sections for the last four sub-TLV
values, but not the first (Resource Block Information).  Why not?

Again in section 2, you say that the sub-TLVs may appear in any order.
You don't say whether all of them are required - is that what's
intended, or may any subset be specified?

In section 3.1 you use the acronym SCSI to mean 'Switching Capability
Specific Information,' which I found confusing.  It would help to
add (SCSI) as part of that sub-section's title.

In section 4 you say "In a rare case where the TLV exceed the IP MTU,
IP fragmentation/reassembly can be used, which is an acceptable
method."  That's probably true for IPv4, but what about IPv6, where
fragmentation must be done by the source node?

There are also a few tiny typos:
 s2.2  s/may have a limited/may have limited/
 s2.4  s/Resources blocks/Resource blocks/  (?)
 s4    s/that exceeds the/that exceed the/
 s6.1  s/New IANA registry/A new IANA registry/
 s6.1.1  s/new IANA registry/a new IANA registry/
 s6.2  s/Refenrence/Reference/  (also, its value should be [This.ID])

Cheers, Nevil
Ex-co-chair, EMAN and IPFIX WGs

--
---------------------------------------------------------------------
 Nevil Brownlee                    Computer Science Department | ITS
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand