GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks

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

Alvaro Retana No Objection

(Alia Atlas; former steering group member) (was Discuss) Yes

Yes (2015-08-27 for -16)
No email
send info
I'd like to see clearer descriptions on particularly the error-handling around multiple TLVs and sub-TLVs. 
I see a few points of ambiguity - as described below.  I think these should be straightforward to clarify but
interoperability could be affected if this isn't done.   Thanks!

In Sec 2, it says "Only one Optical Node Property TLV shall be advertised in each LSA." What is the error-handling if multiple of this TLV are seen?
Is that a SHALL or a "at most one... MUST be advertised"?  I'd expect normative language.

In Sec 2, it says "   Among the sub-TLVs defined above, the Resource Block Pool State sub-
   TLV and Resource Block Shared Access Wavelength Availability are
   dynamic in nature while the rest are static. As such, they can be
   separated out from the rest and be advertised with multiple TE LSAs
   per OSPF router, as described in [RFC3630] and [RFC5250]."
So - one can advertise multiple TE LSAs - each with at most one  Optical Node Property TLV 
and at most one of these sub-TLVs?  If the same sub-TLV appears in different TE LSAs, how
are they merged or is a particular one preferred and the rest ignored?  I see the text in the
previous paragraph of "If more than one copy of a sub-TLV is received,
   only the first one of the same type is processed and the rest are
   ignored upon receipt." but what does the "first one" mean?  Is that decided based on
a particular identifier?

In Sec 3.1, "The format of the SCSI MUST be as depicted in the following figure:" implies that
both the Available Label Sub-TLV and the Shared Backup Label Sub-TLV must be included and
in the specified order.   Please clarify (and use separate diagrams) details about how many times
each sub-TLV can appear, if ordering matters, and how to handle conflicts or duplicates.

End of Sec 4: "In case where the new sub-TLVs or their attendant encodings are
   malformed, the proper action would be to log the problem and ignore..."  First, please be explicit in
what behavior MUST be done.  Is this just for malformed sub-TLVs?  Is it safe to assume that sub-TLVs
further on in the TLV (or following TLVs) can be properly parsed?  Second, please add in some words
about the expected load of logs.

In Sec 2, it's useful to use TBA1, TBA2, etc. instead of reusing TBA - adds to clarity of the text and makes it easier to make sure replacement is done
properly when the values are assigned.

In Sec 3.1, it says "   The technology specific part of the WSON ISCD may include a variable
   number of sub-TLVs called Bandwidth sub-TLVs.  Two types of
   Bandwidth sub-TLV are defined (TBA by IANA):"   If this document is creating the
bandwidth sub-tlv space, then this draft simply assigns initial values - so no need for the "TBA
by IANA".

In Sec 4, "In a typical node configuration, the optical node property TLV will not exceed the IP MTU."
Can you please describe the assumptions about a "typical node configuration"?  In a few years, these
assumptions are likely to have changed.

(Deborah Brungard; former steering group member) Yes

Yes ( for -15)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2015-07-29 for -15)
No email
send info
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

   The following TLV is allocated in this specification.
   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, as follows:

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 as follows:
   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, as follows:

(Ben Campbell; former steering group member) No Objection

No Objection (2015-08-03 for -15)
No email
send info
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.


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?

(Benoît Claise; former steering group member) No Objection

No Objection (2015-08-06 for -15)
No email
send info
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

   "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

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:

	It is comprised of a set of sub-TLVs.

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


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:


	3.1. Switching Capability Specific Information


	3.1. Switching Capability Specific Information (SCSI)

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:


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


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.

(Jari Arkko; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -15)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2015-08-05 for -15)
No email
send info
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?

(Terry Manderson; former steering group member) No Objection

No Objection ( for -15)
No email
send info