Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
"Zhangxian (Xian)" <zhang.xian@huawei.com> Thu, 29 January 2015 16:18 UTC
Return-Path: <zhang.xian@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 0DCA21A0104 for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 08:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.761
X-Spam-Level:
X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, 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 r175ja48sRtE for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 08:17:59 -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 E48841A00E9 for <ccamp@ietf.org>; Thu, 29 Jan 2015 08:17:57 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRW61076; Thu, 29 Jan 2015 16:17:56 +0000 (GMT)
Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 16:17:55 +0000
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.61]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Fri, 30 Jan 2015 00:17:52 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: "lberger@labn.net" <lberger@labn.net>
Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Thread-Index: AQHQOzdWKmSQCof59UKyo5HGi/I8RJzVeP6AgAAF8YCAARI0gIAAGGcAgAATGACAAIfBTg==
Date: Thu, 29 Jan 2015 16:17:51 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B47177034@SZXEMA512-MBS.china.huawei.com>
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> <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm>, <54CA58EC.6050108@labn.net>
In-Reply-To: <54CA58EC.6050108@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.46.89.14]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/dUPf3ubezk8yIipanutZle1eyhs>
Cc: "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: Thu, 29 Jan 2015 16:18:01 -0000
Hi, Lou, I support your proposal. Just a thought: given the massive support of Option 2 from WG, maybe we can reconcile by moving the WG draft forward using either Option 1/3, while writing a short draft to document the update needed to match the to-be-updated G.874.1? So that once it is updated, we can move the draft quickly. Regards, Xian ________________________________________ 发件人: CCAMP [ccamp-bounces@ietf.org] 代表 Lou Berger [lberger@labn.net] 发送时间: 2015年1月29日 23:59 收件人: Leeyoung; adrian@olddog.co.uk; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, Hing-Kam (Kam)'; ggrammel@juniper.net; giomarti@cisco.com 抄送: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org 主题: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode I thought it would be good to let things settle a bit before responding as Shepherd. So option 1 (No definition of proprietary semantics and conflicts are handled outside of the control plane, i.e., belong to operator) was the intent of the WG at the time of publication request. This approach was also aligned with the then, and actually current, state of the ITU-T data plane (and management info) as discussed in our joint meeting. I believe option 3 (dropping the vendor specific option) isn't in conflict with this. There now seems to be support for changing the document to align it with, what I understand is, a planned update to G.874.1. This of course implies that such a change would result in this document being blocked until that update is published in 6 months or so, and assumes no substantive change its contents. Again with Shepherd hat on, I recommend avoiding the additional delay and not tie this document to the planned G.874.1 update at this time, i.e., by following option 1 (or even 3). This allows for a future bis/update that is align with the expected update to G.874.1 once it is published. Comments, objections, support? (AD, authors, chairs, wg, ...) Lou On 01/29/2015 09:51 AM, Leeyoung wrote: > Hi, > > It seems like the world is against Option 1. No big deal, please provide relevant text to support Option 2. > > 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 > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp
- [CCAMP] Vendor-Specific Application Code in draft… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lam, Hing-Kam (Kam)
- Re: [CCAMP] Vendor-Specific Application Code in d… Gert Grammel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lam, Hing-Kam (Kam)
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lam, Hing-Kam (Kam)
- Re: [CCAMP] Vendor-Specific Application Code in d… BRUNGARD, DEBORAH A
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… BRUNGARD, DEBORAH A
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Varma, Eve L (Eve)
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Doolan, Paul (Coriant - US/Irving)
- Re: [CCAMP] Vendor-Specific Application Code in d… Fatai Zhang
- Re: [CCAMP] Vendor-Specific Application Code in d… Dieter Beller
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Huub van Helvoort
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Gert Grammel
- Re: [CCAMP] Vendor-Specific Application Code in d… Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] Vendor-Specific Application Code in d… Zhangxian (Xian)
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Daniele Ceccarelli
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Daniele Ceccarelli
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel