[CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model

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

Hi,

I have done my normal AD review of your document after receiving the
Publication Request.  As usual, the purpose of the review is to catch
issues and nits as early as possible so that they don't get in the way
during IETF last call and IESG evaluation.

The review below includes a few nits and raises a couple of questions.
All of the issues are open for discussion, and I am quite prepared to
hear back that the WG considered things and reached consensus.

For the moment, I have marked the I-D as "Revised I-D Needed".

Thanks for the work,

Adrian

===

As I asked in my email to the CCAMP list, I find it odd that this
document makes no reference to RFC 5307 and the use of IS-IS as a 
routing protocol in GMPLS control of OTN.

---

Section 1 says:

   Specific routing and signaling extensions are defined in [OTN-OSPF]
   and [OTN-RSVP].

I think you might extend this text to note that those two documents and
the extensions they define, specifically address the gaps identified in
this document.

---

I found it hard to see the clear gap analysis in section 9.  I think 
what it says is generic and not specific to OTN - i.e., there is a need
to distinguish switching capabilities from adaptation/termination
capabilities.

Am I missing something?  Why does OTN have this issue?  Should this be
handled as a technology-independent issue?

---

Section 10 has

   The IETF foresees that up to eight priorities must be supported and
   that all of them have to be advertised independently on the number of
   priorities supported by the implementation.  Considering that the
   advertisement of all the different supported signal types will
   originate large LSAs, it is advised to advertise only the information
   related to the really supported priorities.

The language here is a bit odd to me.
... *foresees* that *up*to* eight priorities *must* be supported ...  ?

How about...

[RFC4202] defines 8 priorities for resource availability and usage.

---

Section 11

   Modifications to ISCD/IACD, if needed, have to be addressed in the
   related encoding documents.

I think this document needs to state whether those modifications are
needed.

---

Section 12

   The ODUk label format defined in [RFC4328] could be updated to
   support new signal types defined in [G.709-2012] but would hardly be
   further enhanced to support possible new signal types.

What does "hardly" mean in this text?  So you mean "it would be 
difficult"?  If so....

   The ODUk label format defined in [RFC4328] could be updated to
   support new signal types defined in [G.709-2012] but it would be
   difficult to further enhanced it to support possible new signal
   types.

---

Section 12

   Furthermore such label format may have scalability issues due to the
   high number of labels needed when signaling large LSPs.  For example,
   when an ODU3 is mapped into an ODU4 with 1.25Gbps tributary slots, it
   would require the utilization of thirty-one labels (31*4*8=992 bits)
   to be allocated while an ODUflex into an ODU4 may need up to eighty
   labels (80*4*8=2560 bits).

The maths is flawless.  Does the WG believe that this scenario is 
likely?  Or is it just a theoretical possibility?

I ask because I am cautious about us engineering for fringe cases.

---

I think a number of your Informative references are actually used as
Normative.  I would list

   [RFC3471], [RFC3473], [RFC4202], [RFC4203], [RFC4328], and [RFC5339].