Re: [CCAMP] New drafts addressing the manangement and control of optical interfaces 698.2

<Manuel.Paul@telekom.de> Mon, 01 August 2011 15:40 UTC

Return-Path: <Manuel.Paul@telekom.de>
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 3B52211E80C9 for <ccamp@ietfa.amsl.com>; Mon, 1 Aug 2011 08:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.447
X-Spam-Level: *
X-Spam-Status: No, score=1.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DC_GIF_UNO_LARGO=2.275, EXTRA_MPART_TYPE=1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXf2DpI6eqHt for <ccamp@ietfa.amsl.com>; Mon, 1 Aug 2011 08:40:30 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBA511E80A6 for <ccamp@ietf.org>; Mon, 1 Aug 2011 08:40:29 -0700 (PDT)
Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 01 Aug 2011 17:40:27 +0200
Received: from HE113414.emea1.cds.t-internal.com (10.125.65.80) by HE111527.EMEA1.CDS.T-INTERNAL.COM (10.125.90.86) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 1 Aug 2011 17:40:27 +0200
Received: from HE101452.emea1.cds.t-internal.com ([169.254.2.253]) by HE113414.emea1.cds.t-internal.com ([2002:7cd:4150::7cd:4150]) with mapi; Mon, 1 Aug 2011 17:40:27 +0200
From: Manuel.Paul@telekom.de
To: fu.xihua@zte.com.cn
Date: Mon, 01 Aug 2011 17:40:24 +0200
Thread-Topic: [CCAMP] New drafts addressing the manangement and control of optical interfaces 698.2
Thread-Index: AcxC5MhaChWQYKp0TQeX92qUQoO6vAJhAKVg
Message-ID: <9435EDACD941174099E143BCA2BCD615F7AD0C7CE6@HE101452.emea1.cds.t-internal.com>
References: <D0A3A22C2D7BE64AA7506612C2E9BAB70141E7B63AD3@HE101451.emea1.cds.t-internal.com> <OF68BF843C.A5EFB823-ON482578CE.003A8F1C-482578CE.004043C5@zte.com.cn>
In-Reply-To: <OF68BF843C.A5EFB823-ON482578CE.003A8F1C-482578CE.004043C5@zte.com.cn>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: multipart/related; boundary="_004_9435EDACD941174099E143BCA2BCD615F7AD0C7CE6HE101452emea1_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] New drafts addressing the manangement and control of optical interfaces 698.2
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: Mon, 01 Aug 2011 15:40:32 -0000

Dear Xihua,

Thanks a lot for your comments.
Please see the response below inline marked [MP].

Best regards,
Manuel

________________________________
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of fu.xihua@zte.com.cn
Sent: Friday, July 15, 2011 7:42 AM
To: Kunze, Rüdiger
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] New drafts addressing the manangement and control of optical interfaces 698.2


Hi Authors,

I read through your framework document. Following is my comments.

1. In section 5.1.2, it is not clear for me what's the purpose to use LMP (XML).
Do you mean you use LMP protocol to communicate management information between CL and OM/OD?
[MP:] Yes, here, LMP was primarily intended to provide an out-of-band logical channel between the Client and the optical domain to carry management information (e.g. XML encoded). I.E. here it is scoped to the management plane.
Additionally, in another scenario, LMP could be also used to provide the control plane communication, please see more below.
We will clarify that in the text and figure in the next version.
2. In section 5.2, you mention "LMP must be run between the both end-points of the link
and between the edge node and the first optical network node."
Would you like to clarify what's purpose to run LMP between both end-points of BL?
IMO, many physical interface parameters must be decided to make transmitter and receiver meet the range of interoperability during network planning.
We don't need to use LMP to negotiate physical parameters.
[MP:] This section relates to an advanced scenario where a dynamic control plane is present/in use. Interface capability could be discovered and signaled using LMP.
You mention a solution using a common control plane for transport and client network.
Would you like to clarify the concept of common control plane?
IMO, the control plane is to manage the end points and traffic engineering of TE links as illustrated in following figure.
Suppose the common control plane could control the client network (i.e., router) and these TE links.
But it shouldn't be matter with the control plane within the black box.
[cid:image001.gif@01CC5072.17B6C6D0]

[MP:] Common control plane would mean that both the client and the transport network equipment would be controlled by the same administrative unit, running a single control plane instance.
This would be as represented by the upper example in your figure, while the bottom one matches with the consideration for a (or two) separate and independent control plane instance(s).

3.It is not clear for me what control plane could done for BL. This draft doesn't clearly give any implication for CP.
[MP] I think the question about the application is answered by the consideration above regarding your example. Of course, as can be seen in the v00, the control plane part is not yet finished but work in progress.
Thanks for your comments here, also for the offline talks during the IETF meeting. Will be helpful to progress this section, i.e. to work out how a segmented control approach could work and what would be the protocol implications.

We may need to consider how to dynamic configure end points OAM of black link.
We may evaluate if draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext could apply to BL.

Xihua


<RKunze@telekom.de>
发件人:  ccamp-bounces@ietf.org

2011-07-13 下午 08:12

收件人

<ccamp@ietf.org>

抄送



主题

[CCAMP] New drafts addressing the manangement and control of optical interfaces 698.2










Hi all,

after the discussion we received at IETF Prague meeting and having proposed the draft to ITU-T, we did some
changes and renamed the following drafts dealing with the management of optical interfaces based on ITU-T 698.2 standard.
http://tools.ietf.org/html/draft-kunze-g-698-2-management-control-framework-00
http://tools.ietf.org/html/draft-galimbe-kunze-g-698-2-snmp-mib-00
Both documents focus exclusive on ITU-T specified data plane technologies.
For the authors it is important to find a home within the IETF and we think CCAMP is the right base to do this work.
Please send your comments to list.

Authors of the both documents





Deutsche Telekom AG
Group Technology
Rüdiger Kunze
Goslarer Ufer 35, 10589 Berlin
+49 30 3497 - 3152 (Tel.)
+49 30 3497 - 3153 (Fax)
+49 1702275321 (Mobil)
E-Mail: Ruediger.Kunze@telekom.de
www.telekom.com<http://www.telekom.com>

Life is for sharing.

Deutsche Telekom AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: René Obermann (Chairman),
Dr. Manfred Balz, Reinhard Clemens, Niek Jan van Damme,
Timotheus Höttges, Guido Kerkhoff, Edward R. Kozel, Thomas Sattelberger
Commercial register: Amtsgericht Bonn HRB 6794
Registered office: Bonn
VAT identification no. DE 123475223

Big changes start small – conserve resources by not printing every e-mail.


 _______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp