Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Leeyoung <leeyoung@huawei.com> Mon, 02 February 2015 15:38 UTC

Return-Path: <leeyoung@huawei.com>
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 B53441A02BE for <ccamp@ietfa.amsl.com>; Mon, 2 Feb 2015 07:38:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level:
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 xPpSE2Rj0OwR for <ccamp@ietfa.amsl.com>; Mon, 2 Feb 2015 07:38:45 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5E61A1F01 for <ccamp@ietf.org>; Mon, 2 Feb 2015 07:38:19 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRZ90580; Mon, 02 Feb 2015 15:38:18 +0000 (GMT)
Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 15:38:17 +0000
Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 07:38:14 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Varma, Eve L (Eve)'" <eve.varma@alcatel-lucent.com>, "db3546@att.com" <db3546@att.com>, "'Lam, Hing-Kam (Kam)'" <kam.lam@alcatel-lucent.com>, "ggrammel@juniper.net" <ggrammel@juniper.net>, "giomarti@cisco.com" <giomarti@cisco.com>
Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Thread-Index: AQHQNyyKmWicGibpQEGWYW2s/gCycJzOdnmAgAAengCAA5dgAIAEL7YA//+TloCAAJDSAP//e+qggACJ8QCAAAbcgP//fJJwADNyZIAABPD9MAC9k2qAAAWt9/A=
Date: Mon, 2 Feb 2015 15:38:13 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7FF70@dfweml706-chm>
References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F587@dfweml706-chm> <4A1562797D64E44993C5CBF38CF1BE481284FFD2@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481284FFD2@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-hashedpuzzle: Yksi mu+D ql1I t90Q 4+5y 5CCW ACn5FA== ADG9hQ== ADcrXQ== AFGh2Q== AFlRxw== AFxjRQ== AK0rDQ== AK20lg== ALGRdg== AM1lOA==; 11; YQBkAHIAaQBhAG4AQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA7AGMAYwBhAG0AcAAtAGMAaABhAGkAcgBzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAYwBjAGEAbQBwAEAAaQBlAHQAZgAuAG8AcgBnADsAZABhAG4AaQBlAGwAZQAuAGMAZQBjAGMAYQByAGUAbABsAGkAQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8AbQA7AGQAYgAzADUANAA2AEAAYQB0AHQALgBjAG8AbQA7AGQAcgBhAGYAdAAtAGkAZQB0AGYALQBjAGMAYQBtAHAALQByAHcAYQAtAHcAcwBvAG4ALQBlAG4AYwBvAGQAZQAuAGEAbABsAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAZQB2AGUALgB2AGEAcgBtAGEAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AGcAZwByAGEAbQBtAGUAbABAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA7AGcAaQBvAG0AYQByAHQAaQBAAGMAaQBzAGMAbwAuAGMAbwBtADsAawBhAG0ALgBsAGEAbQBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtADsAcABhAHUAbAAuAGQAbwBvAGwAYQBuAEAAYwBvAHIAaQBhAG4AdAAuAGMAbwBtAA==; Sosha1_v1; 7; {CFBC8794-EF63-49E1-A8C2-2C21A302A012}; bABlAGUAeQBvAHUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Mon, 02 Feb 2015 15:37:34 GMT; UgBFADoAIABbAEMAQwBBAE0AUABdACAAVgBlAG4AZABvAHIALQBTAHAAZQBjAGkAZgBpAGMAIABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABDAG8AZABlACAAaQBuACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAHIAdwBhAC0AdwBzAG8AbgAtAGUAbgBjAG8AZABlAA==
x-cr-puzzleid: {CFBC8794-EF63-49E1-A8C2-2C21A302A012}
x-originating-ip: [10.192.11.186]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/ix19KY3S1Gx1KcefvDUIoFoOTrg>
Cc: "paul.doolan@coriant.com" <paul.doolan@coriant.com>, "ccamp@ietf.org" <ccamp@ietf.org>, "ccamp-chairs@tools.ietf.org" <ccamp-chairs@tools.ietf.org>, "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" <draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org>
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
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: Mon, 02 Feb 2015 15:38:47 -0000

Hi Daniele and Fatai,

Thanks for the resolution. I am still waiting for Adrian's other comments (as part of the AD review) and comments from ITU-T Q6/15 on the Application Codes. Once they are resolved, a revision will be made available.

Regards,
Young

-----Original Message-----
From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] 
Sent: Monday, February 02, 2015 4:14 AM
To: Leeyoung; adrian@olddog.co.uk; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, Hing-Kam (Kam)'; ggrammel@juniper.net; giomarti@cisco.com
Cc: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Working group,

It seems there is a strong willingness to support Vendor Specific Application Codes (a.k.a Option 2).  

This would require putting the draft on hold till the formal approval of G.874.1 (should be July 2015), but we would like not to stop the draft for so long since a lot of other contents are ready to be progressed. 

Our proposal is to move on with option 3 (i.e. Remove the option to include a Vendor-Specific Application Code field.) and add the support for vendor specific application codes later in a BIS or a small, simple and straightforward draft as soon as G.874.1 is approved. 

Young, authors, please update the draft accordingly and maybe add a note saying that  "future work may add support for vendor-specific AI once the ITU-T has completed its work in that area"

Working group, who would find it impossible to live with this as a compromise approach? If you cannot live with this approach, please explain why.

BR
Daniele & Fatai




> -----Original Message-----
> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Leeyoung
> Sent: giovedì 29 gennaio 2015 20:11
> To: adrian@olddog.co.uk; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam,
> Hing-Kam (Kam)'; ggrammel@juniper.net; giomarti@cisco.com
> Cc: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-
> chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
> Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-
> rwa-wson-encode
> 
> Hi Adrian,
> 
> I think you misinterpreted what was said.
> 
> >> Now, what is the purpose of standard FECs and modulations in the AI?
> >> Given several choices each vendor may support in its device, the path
> >> computation would find a matched types for FEC and modulation for a
> given optical path.
> >> This is what is intended when optical signal processing constraints
> >> were proposed as part of path computation constraints in optical
> networks.
> 
> > The case you are making here is for no standard control plane!
> > What is the point of standardising if there is never any interworking?
> > But actually, we know about interworking at the physical layer, and (more
> important) we know about a single, > end-to-end control plane that spans
> multiple vendor devices. It all exists.
> 
> The standard AI allows to match optical processing constraints (including
> FECs and Modulations implied in an AI). This information is advertised that a
> PCE would be able to compute an optical path matching AIs for all the
> devices to dertermine a feasible path. I am talking about this standard
> control plane work. This is what was intended in the draft.
> 
> Regards,
> Young
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Thursday, January 29, 2015 7:24 AM
> To: Leeyoung; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, Hing-Kam
> (Kam)'; ggrammel@juniper.net; giomarti@cisco.com
> Cc: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-
> chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
> Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-
> rwa-wson-encode
> 
> Hi again,
> 
> > There is always a priori knowledge in optical network domain as to who
> > are you interfacing with. So you know which vendor you are interfacing.
> > If you do not know, then you are in trouble.
> 
> Hmmm. It is exactly type of trouble we are trying to detect and protect
> against.
> 
> I refute your statement of a priori knowledge. I think there is a priori
> intention, but not knowledge. Unless you have very good eyesight or
> someone at the other end of the fiber when you give it a tug, you don't
> know. And even then. Fibering errors happen from time to time. Consider, in
> particular a patch panel.
> 
> > Now, what is the purpose of standard FECs and modulations in the AI?
> > Given several choices each vendor may support in its device, the path
> > computation would find a matched types for FEC and modulation for a
> given optical path.
> > This is what is intended when optical signal processing constraints
> > were proposed as part of path computation constraints in optical
> networks.
> 
> 
> The case you are making here is for no standard control plane!
> What is the point of standardising if there is never any interworking?
> But actually, we know about interworking at the physical layer, and (more
> important) we know about a single, end-to-end control plane that spans
> multiple vendor devices. It all exists.
> 
> Of course, we can fall back into the old-style vendor islands, and many like to
> do so. But it is not a compulsory deployment model.
> 
> > There is very little chance for vendor specific FECs and Modulations
> > will match even if they are identified with the OUI code.
> 
> You have it the wrong way round!
> The OUI is largely to protect against expectations of interworking when none
> can exist.
> It might (much less frequently) be used to describe the way that vendorA and
> vendorB pick FECs and modulations in order to achieve interworking.
> 
> Adrian
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp