Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Lou Berger <lberger@labn.net> Thu, 29 January 2015 16:23 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 DDE431A874F for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 08:23:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.449
X-Spam-Level:
X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, 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 eziByuNeEuPI for <ccamp@ietfa.amsl.com>; Thu, 29 Jan 2015 08:23:32 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 82B8C1A8742 for <ccamp@ietf.org>; Thu, 29 Jan 2015 08:23:32 -0800 (PST)
Received: (qmail 14646 invoked by uid 0); 29 Jan 2015 16:23:27 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 29 Jan 2015 16:23:27 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id lsN31p00F2SSUrH01sN6K6; Thu, 29 Jan 2015 09:22:19 -0700
X-Authority-Analysis: v=2.1 cv=BqwOn+n5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=hUXq7yzdp1YA:10 a=Zu_UBlEkk2cA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=YNv0rlydsVwA:10 a=48vgC7mUAAAA:8 a=AEDFM0qtAAAA:8 a=zQP7CpKOAAAA:8 a=OUXY8nFuAAAA:8 a=AUd_NHdVAAAA:8 a=LA_P08GTAAAA:8 a=r2wunU7YzEtRMcvcPpoA:9 a=C1wDX5cZ5RUraAx1:21 a=Pqw4Chk3US1haM5N:21 a=AWzbc7it75AA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4SfO+PfoAoJ/CT6yhKZur84FHhyl/Z+lXt+Ahj/3/a8=; b=qtTrSGISdsEX6hBTGc1PcSatK1UXX86m74/7NwzTqi4aI/s/4dWpMCrqPB9spT0/DzVFodKJz94dROXyH3s4wZjBW5eDDXa3Vnw8xcclNUve/6n+H9mFOsTEDxrbTJPE;
Received: from box313.bluehost.com ([69.89.31.113]:59164 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from <lberger@labn.net>) id 1YGrr1-00073C-1v; Thu, 29 Jan 2015 09:22:03 -0700
Message-ID: <54CA5E28.10005@labn.net>
Date: Thu, 29 Jan 2015 11:22:00 -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: "Zhangxian (Xian)" <zhang.xian@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> <C636AF2FA540124E9B9ACB5A6BECCE6B47177034@SZXEMA512-MBS.china.huawei.com>
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B47177034@SZXEMA512-MBS.china.huawei.com>
Content-Type: text/plain; charset=gbk
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/8zR_CvMoemRjeWlGjhKgVDeu8C8>
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:23:35 -0000

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
>