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
- [CCAMP] AD review of draft-ietf-ccamp-otn-g709-in… Adrian Farrel
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Daniele Ceccarelli
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Adrian Farrel
- [CCAMP] 答复: AD review of draft-ietf-ccamp-otn-g70… Fatai Zhang
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Lou Berger
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Lou Berger
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Adrian Farrel
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Daniele Ceccarelli
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Lou Berger
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Daniele Ceccarelli
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Lou Berger
- Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g70… Adrian Farrel