GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signal-compatibility-ospf-17

Sections 6.1.1 and 6.2.1 correctly say that they're creating new registries, but Sections 6.1 and 6.2 incorrectly say that, when they appear to be only registering TLVs in existing registries.  IANA hasn't reviewed this yet, I see, so I don't know how confused they might be, but it would be good to fix this (also note the URL correction in 6.1):

OLD (6.1)
   New IANA registry will be created for the Optical Node Property TLV
   to allocate a new TLV Type and its Value for this Top Level Node TLV
   in the "Top Level Types in TE LSAs" section of the "OSPF Traffic
   Engineering TLVs" registry located at
   http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-
   eng-tlvs.xhtml.

   The following TLV is allocated in this specification.
NEW
   IANA is asked to register a new TLV for "Optical Node Property".
   The new TLV will be registered in the "Top Level Types in TE LSAs"
   registry in "OSPF Traffic Engineering TLVs", located at
   http://www.iana.org/assignments/ospf-traffic-eng-tlvs, as follows:
END

OLD (6.2)
   A new IANA registry will be created to make the assignment of a new
   value for the existing "Switching Types" TLV of the "GMPLS Signaling
   Parameters" registry located at
   http://www.iana.org/assignments/gmpls-sig-parameters as follows:
NEW
   IANA is asked to register a new TLV for "WSON-LSC capable".
   The new TLV will be registered in the "Switching Types" registry in
   "GMPLS Signaling Parameters", located at
   http://www.iana.org/assignments/gmpls-sig-parameters, as follows:
END

Section 5 (security considerations) says: "This document does not introduce any further security issues other
   than those discussed in [RFC3630], [RFC4203]."

While I don’t doubt the statement is true, it would be helpful to show the thought behind it. In this case, the draft adds new data elements to the OSPF TE LSA. Please consider adding a very short discussion on how the security implications of those elements is similar to or different from the previously existing data elements.

Nits:

Please expand TE and LSA on first mention.

idnits thinks the reference to [G.694.1] is not cited in the body. Is the reference needed?

For the sake of recording the ongoing discussion between the Nevil Brownlee, as OPS-DIR reviewer, and the author (YOUNG)

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.

YOUNG>> Yes. Actually they have already become RFCs. Need to update the reference. 
WSON-Encode is now RFC 7581 and GEN-OSPF RFC 7580. 


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.

YOUNG>> Good point. Will work with IANA on this. 

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

YOUNG>> Actually you are correct. Will add a sub-section for the Resource Block Information with the following text:


   As defined in [RFC7446], the Resource Block Information
   <ResourceBlockInfo> field is used to represent resource signal
   constraints and processing capabilities of a node.


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?

YOUNG>> They are optional TLVs. How about:

OLD
	It is comprised of a set of sub-TLVs.

NEW
	It is comprised of a set of optional sub-TLVs.

END



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.

YOUNG>> Sure. It will be like:

OLD

	3.1. Switching Capability Specific Information

New

	3.1. Switching Capability Specific Information (SCSI)
END



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?

YOUNG>> I am not IPv6 expert. You are probably right on this. How about adding this:

NEW

	For IPv6, a node may use the IPv6 Fragment header to fragment the packet at the source and have it 
      reassembled at the destination(s).

END

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])


YOUNG>> Will correct in the next revision. Thanks.

I have two (non-blocking) questions...

I always get worried when the security considerations
says "nothing to see here, move on, but if you must, do
feel free to look at <other-rfcs>." That is sometimes a
signal that nobody bothered to think about security, but
only thought about how to try keep the security ADs
quiet:-) Can you re-assure me that in this case, you did
think about security?

Is there any interesting new way in which abuse of these
TLVs (either via direct insertion or else by causing
them to be sort-of controlled by sending other traffic)
can be used to control how traffic flows in a network so
that the attacker can better control or predict through
which nodes (or at which wavelengths) some traffic of
interest (to the attacker) will flow? I'd say that the
answer is probably not, but did you consider it?