Re: [CCAMP] Last Call: <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard

Fatai Zhang <zhangfatai@huawei.com> Fri, 06 September 2013 07:34 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 0621221E8084; Fri, 6 Sep 2013 00:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.282
X-Spam-Level:
X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 zlYopmTzrs-n; Fri, 6 Sep 2013 00:34:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0D11E8118; Fri, 6 Sep 2013 00:34:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVC46984; Fri, 06 Sep 2013 07:34:19 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 08:33:26 +0100
Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 08:33:44 +0100
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.152]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0146.000; Fri, 6 Sep 2013 15:33:31 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [CCAMP] Last Call: <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard
Thread-Index: Ac6d1f8U/0fVrXNNRjCEO33cHnCIigAaKmFg//+qbgD/5oRJsA==
Date: Fri, 6 Sep 2013 07:33:29 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF85CA62157@SZXEMA504-MBS.china.huawei.com>
References: <00fe01ce9dd6$2dc59a10$8950ce30$@olddog.co.uk> <F82A4B6D50F9464B8EBA55651F541CF85AF38E3A@SZXEML552-MBS.china.huawei.com> <008e01ce9e56$ef180d30$cd482790$@olddog.co.uk>
In-Reply-To: <008e01ce9e56$ef180d30$cd482790$@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.66.72.159]
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CA62157SZXEMA504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Last Call: <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard
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: Fri, 06 Sep 2013 07:34:27 -0000

Hi Adrian,

I am updating this draft, but one issue is about the new small section.

You said "adding a small section including all of the statements you made in your email", but I really don't know which kind of section should be added to cover various aspects including management tools, OAM, alarm, MIB, etc.

I also suspect the value to have this kind of new section to talk about something (and nothing new), which may not be related to the subject of this draft (ie., RSVP-TE extensions for OTN *connection* establishment).

Therefore, I would like to hear more from you. Could you give a title for this new section?


Best Regards

Fatai

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, August 21, 2013 6:12 PM
To: Fatai Zhang; ietf@ietf.org
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] Last Call: <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard

Hi Fatai,

I think you nicely answered your own questions :-)

I would suggest adding a small section including all of the statements you made in your email. (Well, no need to refer to Berlin and the CCAMP chairs :-)

Cheers,
Adrian

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: 21 August 2013 08:40
To: adrian@olddog.co.uk; ietf@ietf.org
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] Last Call: <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard


Hi Adrian,



Thanks very much.



I can update the nits and editorial issues quickly, but I would like to discuss more with you for the following points to make things clear before I update the draft.



=========================================================================================

Please consider and note what updates to GMPLS management tools are needed.



[Fatai]This has been mentioned in [Framework] document. Did you mean that we need add one sentence in some place of this document to refer to [Framework] document to mention management tools?



Are there any changes to the Alarms that might arise? We have a document for that.



[Fatai] No. RFC4783 is still applicable.



Are there any changes to the way OAM is controlled? We have a document for that.



[Fatai] No, it could be done through NMS or [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext].



Should the new G-PIDs show in the TC MIB managed by IANA at

https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml

This should happen automgically when the feeding registries are updated

but it is probably best to add a specific request for IANA.



[Fatai] Will do that.



Will other MIB work be needed (in the future) to make it possible to

read new information (labels, tspecs) from network devices?



[Fatai] I am not sure. I asked the similar question (not on this draft) during Berlin meeting. The chairs answered that it could be driven by drafts.







Best Regards



Fatai



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, August 21, 2013 2:51 AM
To: ietf@ietf.org
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Last Call: <draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt> (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard



As sponsoring AD I have the following last call comments I hope you will take on

board.



Thanks,

Adrian



Please fix the two lines that are too long (see idnits)



---



Please expand "OTN" on first use in the main text.

Please expand "TS" on its first use.



---



6.2



   The ingress node of an LSP MAY include Label ERO (Explicit Route

   Object) to indicate the label in each hops along the path.



Missing "subobject".



---



6.2.1



   When an upstream node receives a Resv message containing an

   GENERALIZED_LABEL object



s/an/a/



---



Please consider and note what updates to GMPLS management tools are

needed.



Are there any changes to the Alarms that might arise? We have a document

for that.



Are there any changes to the way OAM is controlled? We have a document

for that.



Should the new G-PIDs show in the TC MIB managed by IANA at

https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml

This should happen automgically when the feeding registries are updated

but it is probably best to add a specific request for IANA.



Will other MIB work be needed (in the future) to make it possible to

read new information (labels, tspecs) from network devices?



---



Please fix so that you have three sections:



Authors' Addresses (only those people on the front page)

Contributors (other people who made significant text contributions to

the document)

Acknowledgements (other people who helped with the work)



---



[OTN-OSPF] should be a normative reference for its use to define the

value of the switching type used in signaling.



_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp