Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 29 January 2015 17:17 UTC
Return-Path: <adrian@olddog.co.uk>
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 EF7181A8547 for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 09:17:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.45
X-Spam-Level:
X-Spam-Status: No, score=-99.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 yMEY5n69pnjD for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 09:17:54 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4EA1A701E for <ccamp@ietf.org>; Thu, 29 Jan 2015 09:17:53 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0THHpxd012569; Thu, 29 Jan 2015 17:17:51 GMT
Received: from 950129200 (194-166-224-30.adsl.highway.telekom.at [194.166.224.30]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0THHlfs012474 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2015 17:17:50 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: ccamp@ietf.org
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> <4A1562797D64E44993C5CBF38CF1BE481284DB62@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481284DB62@ESESSMB301.ericsson.se>
Date: Thu, 29 Jan 2015 17:17:45 -0000
Message-ID: <006101d03be7$82516180$86f42480$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJJUQOjjDfAQ8oFRmu1FlrhpmJTlQFT1EnjAetg4z8CJ7+qqAFLKtJcAlkhiAcCIomVewG+WEREAgF2pA4B3gw5sZteyIeg
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21292.001
X-TM-AS-Result: No--35.230-10.0-31-10
X-imss-scan-details: No--35.230-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtG+9Go4BgFPZrE4IzBBqenJveCbyZ3xax7deAKnvBMxfDt5 srv8z/2aHJg6MNOhyoHsUUZmBtLXVS9FtW7XfHueA9lly13c/gFVftPGBTR0rr0rWM4nIpJrcIa DpdIRhp06XjWVhznG94R6ktsj4/uorm3mcraXo0ORfvUfL+585sLiFiL0BG1uYrcY3gxKTqxgbu 9weiOWK8Sn3Mnad3/3EgzaIwkuq2OdLySUmQFkkqtWSWds/km2IZm2INWXDp7+lfDssyh86Neul 29/x8OD4OW+eedJy6KMxND4t+zSAxoeu+OCiwrS8eSmTJSmEv1R3sGN+j7mNO8r+DLQt6+yaBux LsECVpZy5OhXKYJ/x/AhDxMQoG8AUKy/w6wtmG6aVoAi2I40/b1bhFvvQSAEayjbe4qUImPhLW+ nuKkjluAve2ZfFr+nDY48dK45B3w0CYUOpITAYmA/V00XWjDtTPt84VW1BkIQ8QCSP+YM02/91t cqPFxkFPTdWb0B54ve7SIvqh7NRrpoSDOXAaIh/vIcMN/z71uOVtPg9ibsGnt4BUfB+P48/tR55 4lM1S12gzvDp637cCLMRa7gqiBwIaVPgU+koVHThGbP9qB93IBmvqGKeYuqmnnIaNaZOLEVjAea OyL90h1QXE+gJlXHQo0mAKckAx7G2nY1KR7wCW0PWqD0pliRhEIiqNvBrmOdI/DikZ1UPBJo5yr ADTARKYTUsamWzgzvAIaR9qqmkmTaT5Js0UdSJXKk/roE/RCPmFSaq6xM+GXczQlokCRZq+1liY blo0L9VVCUNaKG6nN8NpnKQPh3sk3Xm9yiC76eAiCmPx4NwLij7XOMI0NNooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0=
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/JZ0wEaugT0gC-1W4mQ6-01v8sxI>
Cc: 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
Reply-To: adrian@olddog.co.uk
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 17:17:58 -0000
Hi, It is worth looking at how you would do the bis. Option 1 says that an implementation can put absolutely anything in the field under a single code point. If you want to bis that, you automatically make all implementations broken unless you define a new OI so you would have ... 0 reserved 1 vendor-specific unknown format 2 (in the bis) vendor-specific with OUI Option 3 says that *today* there is no such thing as vendor-specific AI. In that case the code point is not even seen and implementations today cannot do vendor specific stuff. So you would have S=0 reserved And you would bis by S=1 means vendor-specific. Either approach works. Now, let's discuss existing implementations. AFAICS no-one is close to shipping product (please tell me if I am wrong). So there is no rush. Now let's discuss timing. Option 1 and option 3 allow publication soon, with a bis later. The bis would not happen until the ITU-T has finalised the format for vendor-specific AIs Option 2 can be approached two ways a. *Guess* which way the ITU-T will define the vendor-specific AI b. Wait until the ITU-T has finalised the format for vendor-specific AIs. I would like the chairs to help me and the shepherd understand the preferred approach so that we can determine what to do with the document. Thanks, Adrian > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli > Sent: 29 January 2015 16:34 > To: Lou Berger; 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 > > 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 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