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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Jul 2013 12:40:32 +0100

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 31 Jul 2013 10:28:56 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Farrel
> Sent: domenica 28 luglio 2013 13:41
> To: [email-masked]
> Cc: [email-masked]
> Subject: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model
> 
> Hi,
> 
> 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.
> 
> All of the issues are open for discussion, and I am quite prepared to hear back
> that the WG considered things and reached consensus.
> 
> 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."

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

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

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

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

ok

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

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. 

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

OK

> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 31 Jul 2013 13:37:09 +0100

Thanks,

I'll try to get to this in short order. 
I think this document should be batched with the framework (so it will be held
until I can advance both together).

I think that the signaling and routing I-Ds are gated on this document and the
framework.

Cheers,
Adrian

> From: Daniele Ceccarelli [mailto:[email-masked]]
> Sent: 31 July 2013 11:29
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model
> 
> Adrian,
> 
>   [RFC5307] but in the following only a gap analysis with respect to OSPF-TE
is
> provided."
> "The issue shown above is analyzed in an OTN context but it is a general
> technology independent GMPLS limitation."
> 
> > ---
> >
> > Section 10 has
> >
> 	advised to advertise only the information related to the really
supported
> priorities.
> 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.
> 
> 
> >
> > ---
> >

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 31 Jul 2013 13:50:52 +0000

Hi Adrian,

I will update FWK draft after IETF meeting.

Hope you be patient for a while, :-)

Thanks

Fatai

-----邮件原件-----
发件人: Adrian Farrel [mailto:[email-masked]] 
发送时间: 2013年7月31日 20:37
收件人: 'Daniele Ceccarelli'; [email-masked]
抄送: [email-masked]
主题: RE: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model

Thanks,

I'll try to get to this in short order. 
I think this document should be batched with the framework (so it will be held until I can advance both together).

I think that the signaling and routing I-Ds are gated on this document and the framework.

Cheers,
Adrian

> To: [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Adrian Farrel
> > 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
> > All of the issues are open for discussion, and I am quite prepared 
> > to hear
back
> > document
makes
> > no reference to RFC 5307 and the use of IS-IS as a routing protocol 
> > in GMPLS control of OTN.
> >
> 
is
> > 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.
> >
> 
> > what it
says is
> > generic and not specific to OTN - i.e., there is a need to 
> > distinguish
switching
> > Am I missing something?  Why does OTN have this issue?  Should this 
> > be handled as a technology-independent issue?
> >
> "The issue shown above is analyzed in an OTN context but it is a 
> general technology independent GMPLS limitation."
> 
> > ---
> >
> > Section 10 has
> >
> 	all the different supported signal types will originate large LSAs, 
> it
is
supported

---

From: Lou Berger <[email-masked]>
Date: Wed, 31 Jul 2013 13:08:39 -0400

Daniele,
	See comments below.

On 07/31/2013 06:28 AM, Daniele Ceccarelli wrote:
...
>> -----Original Message-----
...
>   [RFC5307] but in the following only a gap analysis with respect to OSPF-TE is provided."

Given that the analysis for 5307 is pretty similar to 4203, I think you
should take a pass at including it as well.  I'm happy to
review/contribute as needed.

Thanks,
Lou (chair & doc shepherd)