Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues
Gert Grammel <ggrammel@juniper.net> Tue, 18 March 2014 09:54 UTC
Return-Path: <ggrammel@juniper.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EF81A06D3 for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 02:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys6ZogOtyyP7 for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 02:54:45 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66C1A06D1 for <ccamp@ietf.org>; Tue, 18 Mar 2014 02:54:45 -0700 (PDT)
Received: from mail7-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Mar 2014 09:54:36 +0000
Received: from mail7-ch1 (localhost [127.0.0.1]) by mail7-ch1-R.bigfish.com (Postfix) with ESMTP id 6B8FE3A00F8; Tue, 18 Mar 2014 09:54:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: VPS-22(zz98dI9371Ic85fhec9I4015I1447I14ffIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hdchz8275ch1d7338h1de098h1033IL1b1984h17326ah8275bh1bc7b9h8275dh18c673h1de097h186068h18602eh1d68deh19bc52i19bc50iz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1a24h1a82h1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h9a9j1155h)
Received-SPF: pass (mail7-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ggrammel@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(164054003)(37854004)(24454002)(189002)(199002)(53754006)(377454003)(31966008)(2201001)(83072002)(94946001)(76576001)(94316002)(81342001)(17760045001)(93516002)(93136001)(85852003)(86362001)(92566001)(69226001)(76796001)(76786001)(74502001)(74662001)(47446002)(81542001)(19273905006)(77096001)(19300405004)(90146001)(74366001)(95416001)(56816005)(16236675002)(97186001)(59766001)(20776003)(80022001)(2656002)(74876001)(33646001)(85306002)(80976001)(74706001)(53806001)(76482001)(87936001)(54356001)(51856001)(46102001)(47976001)(50986001)(54316002)(56776001)(18206015023)(81816001)(15975445006)(19580405001)(79102001)(77982001)(4396001)(63696002)(97336001)(87266001)(65816001)(74316001)(83322001)(49866001)(47736001)(81686001)(66066001)(19580395003)(95666003)(15202345003)(24736002)(16866105001)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB563; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:347CF1E4.A0C6931D.31D1F54B.42E63183.206EC; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail7-ch1 (localhost.localdomain [127.0.0.1]) by mail7-ch1 (MessageSwitch) id 1395136473749143_18082; Tue, 18 Mar 2014 09:54:33 +0000 (UTC)
Received: from CH1EHSMHS026.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail7-ch1.bigfish.com (Postfix) with ESMTP id B1698320242; Tue, 18 Mar 2014 09:54:33 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Mar 2014 09:54:33 +0000
Received: from BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 18 Mar 2014 09:54:32 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 09:54:29 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.6.242]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.6.233]) with mapi id 15.00.0898.005; Tue, 18 Mar 2014 09:54:29 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: Fatai Zhang <zhangfatai@huawei.com>, "Gabriele Maria Galimberti (ggalimbe)" <ggalimbe@cisco.com>, John E Drake <jdrake@juniper.net>, Dieter Beller <Dieter.Beller@alcatel-lucent.com>, "RKunze@telekom.de" <RKunze@telekom.de>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues
Thread-Index: Ac8+yaJXH8vwWfWRQbyQfVfsHVxr9AABaYCAABUjWwAADUUFgAAAg5QAAAndvDAAgP56AAAMmJwAAAG0MCAABZPMgAAeJ0AAAA7s2eA=
Date: Tue, 18 Mar 2014 09:54:29 +0000
Message-ID: <f92eaf1ed028446bba8bdfc7b4afc053@BN1PR05MB041.namprd05.prod.outlook.com>
References: <f5947c5e2d26418dad8728e9598d60bc@BN1PR05MB041.namprd05.prod.outlook.com> <CF4C9DC1.5AE48%ggalimbe@cisco.com> <F82A4B6D50F9464B8EBA55651F541CF85CAD8C0C@SZXEMA504-MBS.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF85CAD8C0C@SZXEMA504-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.239.10]
x-forefront-prvs: 0154C61618
Content-Type: multipart/related; boundary="_004_f92eaf1ed028446bba8bdfc7b4afc053BN1PR05MB041namprd05pro_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/IabN2JtQaG9ZUag26x6fzkLQWTk
Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 18 Mar 2014 09:54:52 -0000
Fatai, The xNI use case discussion can go forever but it is futile. As an example, TCP/IP is a fine way to access a directory server. However is it an allowed protocol for the UNI? And what about ftp, http, ppp, l2tp, ....? LMP is a protocol which use cases are described in RFC4204 and RFC4209 and does not cover G.698.2 physical interfaces yet. This is the addition we'd like to make. Then any operator can decide whether and where to use LMP, just like for all other protocols defined by IETF like: SNMP, LDP, RSVP, OSPF, ISIS, BGP, ..... If LMP is activated between a pair of nodes, it just works as is. Gert From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: 18 March 2014 03:05 To: Gabriele Maria Galimberti (ggalimbe); Gert Grammel; John E Drake; Dieter Beller; RKunze@telekom.de; ccamp@ietf.org Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Gert and Gabriele, I assume that CCAMP people can understand what I said about UNI/ENNI/INNI, or you can interpret them as UNI, inter-domain, intra-domain. As Gabriele said that Black link could be used on UNI/ENNI/INNI, so these scenairos should be addressed clearly, because there is fundamental difference between these scenarios. I think RFC4204 is for intra-domain case like other RFCs when there is no 'UNI', or 'inter-domain' (or explicit specific scope in the subject) included in the file name of the drafts. Best Regards Fatai From: Gabriele Maria Galimberti (ggalimbe) [mailto:ggalimbe@cisco.com] Sent: Monday, March 17, 2014 7:42 PM To: Gert Grammel; Fatai Zhang; John E Drake; Dieter Beller; RKunze@telekom.de<mailto:RKunze@telekom.de>; ccamp@ietf.org<mailto:ccamp@ietf.org> Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues I agree Gert, Re-stating LMP is used to manage a link between two interfaces, whatever they are. Regards, Gabriele [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Technical Leader Cisco Photonics Srl Via Philips, 12 20900 - Monza (MI) Italy www.cisco.com/global/IT/<http://www.cisco.com/global/IT/> ggalimbe@cisco.com<mailto:ggalimbe@cisco.com> Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>> Date: Monday, March 17, 2014 12:39 PM To: Gabriele Galimberti <ggalimbe@cisco.com<mailto:ggalimbe@cisco.com>>, Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>, John Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>, Dieter Beller <Dieter.Beller@alcatel-lucent.com<mailto:Dieter.Beller@alcatel-lucent.com>>, "RKunze@telekom.de<mailto:RKunze@telekom.de>" <RKunze@telekom.de<mailto:RKunze@telekom.de>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>> Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Fatai & Gabriele, given the lack of definition for UNI/ENNI/INNI in IETF, we better focus on protocols in this discussion. As a reminder: LMP is described in RFC4204 and doesn't contain any of the 3 buzzwords just mentioned. Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Gabriele Maria Galimberti (ggalimbe) Sent: 17 March 2014 09:14 To: Fatai Zhang; John E Drake; Dieter Beller; RKunze@telekom.de<mailto:RKunze@telekom.de>; ccamp@ietf.org<mailto:ccamp@ietf.org> Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Fatai, Black link lies between a DWDM transceiver and a DWDM network (e.g. ROADM). So on UNI for sure. But, if You have Regenerators in the DWDM network the black link can be on the E-NNI and I-NNI. Regards, Gabriele [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Technical Leader Cisco Photonics Srl Via Philips, 12 20900 - Monza (MI) Italy www.cisco.com/global/IT/<http://www.cisco.com/global/IT/> ggalimbe@cisco.com<mailto:ggalimbe@cisco.com> Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>> Date: Monday, March 17, 2014 3:12 AM To: John Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>, Gabriele Galimberti <ggalimbe@cisco.com<mailto:ggalimbe@cisco.com>>, Dieter Beller <Dieter.Beller@alcatel-lucent.com<mailto:Dieter.Beller@alcatel-lucent.com>>, "RKunze@telekom.de<mailto:RKunze@telekom.de>" <RKunze@telekom.de<mailto:RKunze@telekom.de>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>> Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi John, Thanks, I knew RFC4207 & RFC4209 and LMP is optional and more (~100%) used in I-NNI context. My concern could be stated in another way more explicitly: Usecases or scenarios are needed to describe where the black link lies, UNI, E-NNI or I-NNI, and then describe why LMP ext is needed, rather than bring out a lot of parameters to be carried in LMP protocol without justification. Best Regards Fatai From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, March 14, 2014 8:44 PM To: Fatai Zhang; Gabriele Maria Galimberti (ggalimbe); Dieter Beller; RKunze@telekom.de<mailto:RKunze@telekom.de>; ccamp@ietf.org<mailto:ccamp@ietf.org> Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Fatai, LMP already has technology specific extensions for SDH and WDM. Yours Irrespectively, John From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang Sent: Friday, March 14, 2014 12:57 AM To: Gabriele Maria Galimberti (ggalimbe); Dieter Beller; RKunze@telekom.de<mailto:RKunze@telekom.de>; ccamp@ietf.org<mailto:ccamp@ietf.org> Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Gabriele, I prefer the first option, because CCAMP always follow the *G*MPLS principle: generic/generalized->specific. Note that you did not clarify how to justify which parameters can/(can not) be exchanged. Best Regards Fatai From: Gabriele Maria Galimberti (ggalimbe) [mailto:ggalimbe@cisco.com] Sent: Friday, March 14, 2014 3:42 PM To: Fatai Zhang; Dieter Beller; RKunze@telekom.de<mailto:RKunze@telekom.de>; ccamp@ietf.org<mailto:ccamp@ietf.org> Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi All, Thanks for the comments and suggestion. The first action I would take is update the draft with the explanations requested during the ccamp session and in mailing list. I'm not aware of any LMP extensions to support other technologies as Fatai is asking (apart the recent draft on sson), I think this can be a matter of collaboration Discussing also whether to extend the existing draft or propose a new one. I prefer the second option. I'd also note that the LMP is not an extension of the UNI, LMP is a management protocol to help interface management: Discovery, negotiation, alarm correlation, etc. It can run on interfaces not "served" by UNI e.g. On spans between ROADMS. Regards, Gabriele [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Technical Leader Cisco Photonics Srl Via Philips, 12 20900 - Monza (MI) Italy www.cisco.com/global/IT/<http://www.cisco.com/global/IT/> ggalimbe@cisco.com<mailto:ggalimbe@cisco.com> Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>> Date: Friday, March 14, 2014 2:22 AM To: Dieter Beller <Dieter.Beller@alcatel-lucent.com<mailto:Dieter.Beller@alcatel-lucent.com>>, "RKunze@telekom.de<mailto:RKunze@telekom.de>" <RKunze@telekom.de<mailto:RKunze@telekom.de>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>> Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Ruediger and other authors, I agree with Dieter's point. Is it really known what information can/should be exchanged and what can/should not? How to justify? In addition, do you see any draft about LMP ext over UNI for other technologies such as OTN, WSON, SDH, etc. defined in CCAMP? If no, why not make this draft more generic? I would also kindly suggest the authors have a look at the OIF UNI IAs (UNI 1.0 & UNI 2.0 and their difference) to see if it really makes sense to have LMP ext over UNI. Best Regards Fatai From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Thursday, March 13, 2014 11:17 PM To: RKunze@telekom.de<mailto:RKunze@telekom.de>; ccamp@ietf.org<mailto:ccamp@ietf.org> Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Ruediger, On 13.03.2014 15:36, RKunze@telekom.de<mailto:RKunze@telekom.de> wrote: Hi all, Huub and Dieter mentioned during the CAMP session in London that ITU-T Q6 has some concerns about additional values in document. Huub mentioned that - I asked a follow-up question regarding the exchange of power values (see below). Gabriele mentioned the reason for adding these values and we will update the documents with explaining text. During our common meeting with ITU-T at IETF 86 Pete Anslow mentioned: Transmit power may be useful, beyond that I cannot think of anything else you may want to set. If you guys have still concerns lets discuss these points on the list. The question I have is the following: The draft defines LMP protocol messages (sub-objects) to convey the (current?) Output Power at the Ss reference point and the Current Input Power at the Rs reference point from OXC1 to OLS1 and OXC2 to OLS2, respectively. This is my interpretation. Now, I would like to understand for what purposes these power values are exchanged. My suggestion at the meeting was to add some explanatory text to the draft describing the application that makes use of these values, i.e., that motivates the definition of these LMP extensions. Thanks, Dieter Best regards Ruediger _______________________________________________ CCAMP mailing list CCAMP@ietf.org<mailto:CCAMP@ietf.org>
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Fatai Zhang
- [CCAMP] G.698.2 MIB concerns addressed by ITU-T c… RKunze
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Dieter Beller
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Fatai Zhang
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… John E Drake
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… John E Drake
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Huub van Helvoort
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Gert Grammel
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Huub van Helvoort
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Lou Berger
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Fatai Zhang
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Gert Grammel
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… John E Drake
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Fatai Zhang
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Gert Grammel
- Re: [CCAMP] G.698.2 MIB concerns addressed by ITU… Fatai Zhang