[CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3

["Adrian Farrel" <[e-mail]>]

Hi authors and working group,

I have done my usual AD review on receiving a publication request for
this document to smooth out any issues before IETF last call and IESG
evaluation.

As you'll see below, I have a few small issues that I would like to work
through.  The result will either be some email discussion where you 
convince me that no change is needed, or a revised version of the 
document.

Thanks for the work,
Adrian

===

I have a thread with the authors about why they need to list nine 
authors on the front page. The RFC Editor has a norm of no more than
five unless there is a specific reason.

---

This document does not update 4203. Extending mechanisms is not an 
update, and this document doesn't really even extend the mechanisms; it
simply defines a new ISCD and describes how it is used.

---

Section 2 has a reference to [swcaps-update]. I suspect this is meant to
be draft-ietf-ccamp-swcaps-update.  You need to add this to the
informative references section.

---

Section 2 is wrongly named! The section does describe the requirements,
but there is actually nothing in the section that is specific to OSPF 
and certainly no description of OSPF extensions.

I found the material useful, but wondered why it was in this document
and not in the information model document since it perfectly describes
the information model that needs to be applied.  I am not requiring you
to do anything about this, but I would ask you think hard about whether
this text should be moved to the other document and simply pointed to
from here.

---

Section 3 is a fine and concise section. But it seems to me that this
material also belongs in the information model document, not here.
Again, I am not requiring you to make a change here, but please think 
about whether the section could be moved and replaced with a pointer.

---

Section 4

OLD
   - Encoding Type = G.709 ODUk (Digital Path) [as defined in RFC4328]
NEW
   - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
END

---

The description of the table in section 4 caused me some grief. You 
have...

   The bandwidth unit is in bytes per second and the encoding MUST
   be in Institute of Electrical and Electronic Engineers (IEEE)
   floating point format.  The discrete values for various ODUs is shown
   in the table below.

Could you please do two things:

1. Remind the reader that there are 1000 bits in a kbit according to
   normal practices in telecommunications. (Probably add a note to the
   quoted text.)
2. Clarify that the third column shows a floating point value. (Update
   the column heading.)


However, I do also note that the use of bandwidth in section 4.1.3 are
described as (for example)...

      This field
      MUST be set to the bandwidth, in bits/s in IEEE floating point
      format, available at the indicated Signal Type for a particular
      priority level.

So you also need to sort that out.

---

Section 4.
In the table, could you fix up the notation of ODU3 to use 0x not 0X

---

I wonder whether the text and figure for the example in Figure 10 needs
its own section.

---

I think there are some issues (or possibly some unspoken points) with
section 6.

1. Suppose you have an old implementation. How will it treat these new
   advertisements?
   For this you are just stating facts. There is nothing you can define
   because you cannot influence how old implementations work. But you
   can say how they will behave according to existing specs.

2. If a new implementation only supports this spec and not RFC 4328 how
   will it handle an RFC 4328 advertisement? 
   This is something you can and must describe.

3. For a new implementation that supports this spec and RFC 4328, I don't
   understand what you have written.

     When nodes support both advertisement
     methods, implementations MUST support the configuration of which
     advertisement method is followed.

   I *think* this says that 
   - a node MUST NOT use more than one advertisement method to advertise
     the resources on a single OTN link
   It also appears to say that
   - a node MUST NOT use more than one advertisement method to advertise
     across *all* of its advertisements

   You go on to say...

     This enables
     nodes following each method to identify similar supporting nodes 
     and compute paths using only the appropriate nodes.

   ...which seems to imply that it is not possible to compute a path
   end-to-end across nodes using a mix of the old and new advertisement 
   types. Is that *really* what you want to say?

---

It might be helpful to break section 8 into subsections.

---

Section 8

For the new Switching Type you need to remind IANA to make the update
in the IANA-GMPLS-TC-MIB at 
https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib

---

Section 8


   Upon approval of this document, IANA will create and maintain a new
   registry, the "Types for sub-TLVs of OTN-TDM SCSI (Switch Capability
   Specific Information)" registry under the "Open Shortest Path First
   (OSPF) Traffic Engineering TLVs" registry, see http://www.iana.org/
   assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml, with the
   TLV types as follows:


      This document defines new TLV types as follows:

   Value      Sub-TLV                       Reference
   ---------  --------------------------    ----------
   0           Reserved                     [This.I-D]

1. What does "Reserved" mean? Does it mean "Reserved and not to be
   allocated"? Does it mean "Reserved but a future RFC may assign it"?
   Does it mean "Unassigned and available for normal allocation"?
   You need to decide and make it clear for IANA

2. IANA will need to know what the range of available values is.
   3 up to what limit?