Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Thu, 29 January 2015 16:34 UTC
Return-Path: <daniele.ceccarelli@ericsson.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 893061A874E for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 08:34:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level:
X-Spam-Status: No, score=-1.751 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] 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 BBVGWCAVOlGP for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 08:34:04 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB051A19FA for <ccamp@ietf.org>; Thu, 29 Jan 2015 08:34:03 -0800 (PST)
X-AuditID: c1b4fb2d-f79fc6d000001087-47-54ca60f92ac0
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8F.DB.04231.9F06AC45; Thu, 29 Jan 2015 17:34:01 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.154]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 17:34:00 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Lou Berger <lberger@labn.net>, "Zhangxian (Xian)" <zhang.xian@huawei.com>
Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Thread-Index: AQHQNyYU8oHKyXj2jUeONQmhoT7wnpzN2eyAgAAFu4CAAB6eAIADl18AgAQvtgCAAB3lAIAABoMAgAACnYCAAAM+AIAABtyAgAAF8oCAARIzgIAAGGgAgAATFwCAAAUVgIAAASkAgAASukA=
Date: Thu, 29 Jan 2015 16:34:00 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE481284DB62@ESESSMB301.ericsson.se>
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> <C636AF2FA540124E9B9ACB5A6BECCE6B47177034@SZXEMA512-MBS.china.huawei.com> <54CA5E28.10005@labn.net>
In-Reply-To: <54CA5E28.10005@labn.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3RvdnwqkQg99T1SymHj3GZvFkzg0W i2kLT7FZdDS/ZbFYvK2TxYHVo+XIW1aPJUt+Mnl82NTM5vHl8me2AJYoLpuU1JzMstQifbsE rowf67uZCta5VNy61sXawHjGqYuRk0NCwETicfMmFghbTOLCvfVsXYxcHEICRxglWjsbGSGc JYwS3VNnsnYxcnCwCVhJPDnkA9IgIuAr8eH8UmaQGmaBq4wSZ+etYgSpERaIlnj4lAmiJkai +TvEAhGBeYwSrzcHg9gsAqoSd37tBSvnBZpz7A8XSFhI4BuzxJcXjCA2p4CaxIeuP2BjGAVk JSbsXgQWZxYQl7j1ZD4TxM0CEkv2nGeGsEUlXj7+xwphK0pcnb6cCaJeS2Jew28oW1FiSvdD dhCbV0BQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5da sokRGG8Ht/zW3cG4+rXjIUYBDkYlHl6DRSdDhFgTy4orcw8xSnOwKInz2hkfChESSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAyCx9vpzxoqXHk1nqRXW931Jq97G+t7/zwq+hbtuHEO+nattN Vu9eUPiqQ4DlQD7bpy8Cs817/W+fFdA23LV+yu1JPk7uxzknXP5UtKH2opuj1pUpQte3fTs+ bZ7sXNki1/CJTbact88/s75rbzO5nTmIP7RTKMaoekn1l2Qes3ds+7+1tTFxKLEUZyQaajEX FScCANX8GbGYAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/qF1z8dT_I7PVIw5dzotJhnfK59s>
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:34:06 -0000
I think Xian's proposal makes sense. I would like not to hold the draft for 6 more months. As chair I would suggest to go for option 1 or 3 and then go for a bis when G.874.1 will be consented. As contributor, among 1 and 3 I would prefer 1 but I think 3 leaves more room for a simple and straightforward bis. Opinions on this last statement? BR Daniele > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: giovedì 29 gennaio 2015 17:22 > To: Zhangxian (Xian) > Cc: 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 > > On 01/29/2015 11:17 AM, Zhangxian (Xian) wrote: > > 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. > > > > Seems right to me (as contributor) > > Lou > > > 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 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