Ballot for draft-ietf-ccamp-wson-signal-compatibility-ospf
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
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.
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?