Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Lou Berger <lberger@labn.net> Thu, 29 January 2015 17:33 UTC
Return-Path: <lberger@labn.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 9B3D61A8732 for <ccamp@ietfa.amsl.com>;
Thu, 29 Jan 2015 09:33:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.172
X-Spam-Level: *
X-Spam-Status: No,
score=1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334,
MIME_CHARSET_FARAWAY=2.45] autolearn=no
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 EHRgP-Laz0WD for
<ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 09:33:28 -0800 (PST)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz
[69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id
A75B91A873A for <ccamp@ietf.org>; Thu, 29 Jan 2015 09:32:57 -0800 (PST)
Received: from localhost ([::1]:58806 helo=[127.0.0.1]) by
newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim
4.84) (envelope-from <lberger@labn.net>) id 1YGsxc-00009q-Dr;
Thu, 29 Jan 2015 20:32:56 +0300
Message-ID: <54CA6EC6.702@labn.net>
Date: Thu, 29 Jan 2015 12:32:54 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, 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>
<006101d03be7$82516180$86f42480$@olddog.co.uk>
In-Reply-To: <006101d03be7$82516180$86f42480$@olddog.co.uk>
Content-Type: text/plain; charset=gbk
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id:
lberger@blabn.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/HjGvuziv7iHmyc3zZ0_dSQH6AZs>
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: lberger@labn.net
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:33:30 -0000
Adrian, > 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. > I read your message as saying you think option 3 is the better way to go wrt a future bis. I see traffic on the list supporting this. As Shepherd I think this would be fine. Unless I'm misreading you, let's move forward with making the changes to the document to drop support for "vendor-specific unknown format". It will take a day or two for the authors to get the revision out, and this will give others a chance to chime in (i.e, oppose) this if they disagree. Thanks, Lou On 01/29/2015 12:17 PM, Adrian Farrel wrote: > 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 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