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

Lou Berger <> Thu, 29 January 2015 16:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DDE431A874F for <>; Thu, 29 Jan 2015 08:23:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.449
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eziByuNeEuPI for <>; Thu, 29 Jan 2015 08:23:32 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 82B8C1A8742 for <>; 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) ( by with SMTP; 29 Jan 2015 16:23:27 -0000
Received: from ([]) 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;; 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 ([]:59164 helo=[]) by with esmtpa (Exim 4.82) (envelope-from <>) id 1YGrr1-00073C-1v; Thu, 29 Jan 2015 09:22:03 -0700
Message-ID: <>
Date: Thu, 29 Jan 2015 11:22:00 -0500
From: Lou Berger <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Zhangxian (Xian)" <>
References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <> <086901d03b3a$c7386c10$55a94430$> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$> <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm>, <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=gbk
Content-Transfer-Encoding: 8bit
X-Identified-User: {} {sentby:smtp auth authed with}
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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)


> Regards,
> Xian
> ________________________________________
> 发件人: CCAMP [] 代表 Lou Berger []
> 发送时间: 2015年1月29日 23:59
> 收件人: Leeyoung;; 'Varma, Eve L (Eve)';; 'Lam, Hing-Kam (Kam)';;
> 抄送:;;;
> 主题: 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 []
>> Sent: Thursday, January 29, 2015 7:24 AM
>> To: Leeyoung; 'Varma, Eve L (Eve)';; 'Lam, Hing-Kam (Kam)';;
>> Cc:;;;
>> 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 mailing list