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

Adrian,

Thanks for your review and suggestions.
The document has been updated and inline below you can find comments on the modifications made.

Thanks
The authors

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Adrian Farrel
> Sent: domenica 28 luglio 2013 13:41
> To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model
> 
> 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.
> 

At the end of the intro we added the following sentence:
"  As far as it concerns routing, analogous considerations apply to IS-IS
  [RFC5307] but in the following only a gap analysis with respect to OSPF-TE is provided."

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

OK. The following text has been added:
"Specific routing and
  signaling extensions defined in [OTN-OSPF] and [OTN-RSVP] 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?
>
Added the following text at the end of section 9: 

"The issue shown above is analyzed in an OTN context but it is a general technology independent GMPLS limitation."

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

[RFC4202] defines 8 priorities for resource availability and usage.  
	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.

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

Sentence dropped and added this one at the end of the section:
"What said above implies augmenting both the ISCD and the IACD."

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

ok

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

Multiplexing an ODU3 or an ODUflex into an ODU4 is a pretty common scenario. 100Gbps lambdas are being widely deployed and OTN is used to groom traffic. 

> 
> ---
> 
> I think a number of your Informative references are actually used as
> Normative.  I would list
> 
>    [RFC3471], [RFC3473], [RFC4202], [RFC4203], [RFC4328], and [RFC5339].

OK

> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp