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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Aug 2013 19:24:47 +0100

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?

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 27 Aug 2013 15:00:25 +0000

Hi Adrian,

Thanks for the review. Let's see in line if I manage to convince you.

BR
Daniele

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Farrel
> Sent: venerdì 23 agosto 2013 20:25
> To: [email-masked]
> Cc: [email-masked]
> Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ospf-g709v3
> 
> 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.
> 
> 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.
> 
[[DC]] working on that to reduce to <=5

> simply defines a new ISCD and describes how it is used.
[[DC]] Reasonable. Removed.
> 
> ---
> 
> 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.
> 
[[DC]] added
> ---
> 
> 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.

[[DC]] you're right, there is no OSPF extension but I think the section is a good intro to what comes next.
How about deleting section 2 and moving all the text at the end of the intro? (section1).

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

[[DC]] Maybe this one is a better candidate for moving to the info model draft. How about between section 2 and section 3 of the info model draft?

> 
> ---
> 
> 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
> 
[[DC]] ok
> ---
> 
> The description of the table in section 4 caused me some grief. You have...
> 
[[DC]] done
> So you also need to sort that out.

[[DC]] right, either we need to express the bandwidth in bits/s or bytes/sec everywhere. Any preference? Bytes/sec is ok? 

> In the table, could you fix up the notation of ODU3 to use 0x not 0X
[[DC]] done
> ---
> 
> I wonder whether the text and figure for the example in Figure 10 needs its
> own section.
> 
[[DC]] the whole example 5.2.1 is an example of different TS granularities utilization. Figure 9 shows the encoding and figure 10 shows when such a can occur. I would say it make sense to have them in the same section but I am open to change if needed. 
>    can say how they will behave according to existing specs.

[[DC]] don't remember if unknown values are silently discarded or blindly forwarded but if we say something we fall in the same issue of information repeated over different documents. I.e. if some day RFC4203 is updated we need to update this id also. Maybe we could say that "old nodes" behave as described in RFC4203

>    This is something you can and must describe.

[[DC]] ok. How about: 
"All implementations of this document MAY support also advertisement as
    defined in RFC4328. In case they don't, they MUST flood OSPF message without modifying them. "

>      across *all* of its advertisements

[[DC]]  How about:
  " When nodes support both advertisement
    methods, they MUST NOT use more than one advertisement method to advertise
   the resources on a single OTN link and across all of its advertisements.

>    types. Is that *really* what you want to say?

[[DC]] An old node cannot understand new advertisement, hence can only establish lsps along a path of old nodes only.
A new node may not understand old advertisement and hence only e able to setup an lsp along a path of new nodes only.
If a new node understands old advertisement it is possible to setup lsps along a path including a mix of new and old nodes.
This is the idea. If it is acceptable could you please help me with some text clearly stating it?

> It might be helpful to break section 8 into subsections.
[[DC]] switching types and new tlvs I guess. Correct?
> ---
> 
> Section 8
> 
> For the new Switching Type you need to remind IANA to make the update in
> the IANA-GMPLS-TC-MIB at
[[DC]] ok
>       This document defines new TLV types as follows:

[[DC]] personally don't care. Looking at recent RFCs I only found "reserved". Suggestions are welcome.

> 2. IANA will need to know what the range of available values is.

[[DC]]  I've added: 
3-65535	    Unassigned. 
We might consider splitting into two ranges. A range unassigned and one for experimental use? (just loud thinking). Suggestions?
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp