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
>