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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 31 July 2013 12:39 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3511E817E for <ccamp@ietfa.amsl.com>; Wed, 31 Jul 2013 05:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level:
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Coke5D46SH52 for <ccamp@ietfa.amsl.com>; Wed, 31 Jul 2013 05:39:08 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id ADC9C21F9D4C for <ccamp@ietf.org>; Wed, 31 Jul 2013 05:37:14 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6VCbBpK005207; Wed, 31 Jul 2013 13:37:12 +0100
Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6VCbAGU005180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jul 2013 13:37:11 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Daniele Ceccarelli' <daniele.ceccarelli@ericsson.com>, draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org
References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se>
Date: Wed, 31 Jul 2013 13:37:09 +0100
Message-ID: <04d201ce8dea$ad29bb20$077d3160$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIXx93VA/UdhQko2wImjUTLAiqMbQK/MUvxmNZLDeA=
Content-Language: en-gb
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2013 12:39:13 -0000

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

> -----Original Message-----
> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> Sent: 31 July 2013 11:29
> To: adrian@olddog.co.uk; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org
> Cc: ccamp@ietf.org
> Subject: 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