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

Fatai Zhang <zhangfatai@huawei.com> Wed, 31 July 2013 13:51 UTC

Return-Path: <zhangfatai@huawei.com>
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 5F6D821F9CCA for <ccamp@ietfa.amsl.com>; Wed, 31 Jul 2013 06:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.186
X-Spam-Level: *
X-Spam-Status: No, score=1.186 tagged_above=-999 required=5 tests=[AWL=-1.602, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 snxmrDxTH0KJ for <ccamp@ietfa.amsl.com>; Wed, 31 Jul 2013 06:51:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90D0321F9EA7 for <ccamp@ietf.org>; Wed, 31 Jul 2013 06:51:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVP41337; Wed, 31 Jul 2013 13:51:48 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 14:51:24 +0100
Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 14:51:35 +0100
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 21:50:52 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Daniele Ceccarelli'" <daniele.ceccarelli@ericsson.com>, "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" <draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org>
Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model
Thread-Index: Ac6LhtnSfQOotGSxTSGTJyWDc179HQCSrD6A//+sJoD//2aK8A==
Date: Wed, 31 Jul 2013 13:50:52 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF84EE43FF6@SZXEML552-MBX.china.huawei.com>
References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <04d201ce8dea$ad29bb20$077d3160$@olddog.co.uk>
In-Reply-To: <04d201ce8dea$ad29bb20$077d3160$@olddog.co.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.128.105]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: [CCAMP] =?gb2312?b?tPC4tDogIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNj?= =?gb2312?b?YW1wLW90bi1nNzA5LWluZm8tbW9kZWw=?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 13:51:59 -0000

Hi Adrian,

I will update FWK draft after IETF meeting.

Hope you be patient for a while, :-)

Thanks

Fatai



-----邮件原件-----
发件人: Adrian Farrel [mailto:adrian@olddog.co.uk] 
发送时间: 2013年7月31日 20:37
收件人: 'Daniele Ceccarelli'; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org
抄送: ccamp@ietf.org
主题: 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

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