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

"Gabriele Maria Galimberti (ggalimbe)" <> Thu, 29 January 2015 16:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C00C51A03A8 for <>; Thu, 29 Jan 2015 08:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ex6L-xu1ktwU for <>; Thu, 29 Jan 2015 08:07:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 263E41A047A for <>; Thu, 29 Jan 2015 08:07:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2855; q=dns/txt; s=iport; t=1422547660; x=1423757260; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f6O7xsoz0llI0RDZoChZzu8XGlde8qGyK5jezWCmHq8=; b=SgEew2GMMK2303NhxR7BAPJyTnZBvbE86GQjRuLRK3rZL9PxmUqCTB4e LFkH1ZTiTPVmzAGf9SdTBI+bne/SxpdFqayQZ5vwPPgt+eCygviRbLBor JCSSSdTy3Zocv4CjqemGD4GQkdp0fpPWuDJ7r7duEzwzqyj+0klpGITgR c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.09,486,1418083200"; d="scan'208";a="391760388"
Received: from ([]) by with ESMTP; 29 Jan 2015 16:07:30 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t0TG7TQw015018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 16:07:29 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 10:07:29 -0600
From: "Gabriele Maria Galimberti (ggalimbe)" <>
To: "" <>, "'Leeyoung'" <>, "'Varma, Eve L (Eve)'" <>, "" <>, "'Lam, Hing-Kam (Kam)'" <>, "" <>, "Giovanni Martinelli (giomarti)" <>
Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Thread-Index: AQHQO92tg2blSM4Jd0q0kccY3X7UUA==
Date: Thu, 29 Jan 2015 16:07:28 +0000
Message-ID: <>
In-Reply-To: <00ff01d03bc6$d84bbcf0$88e336d0$>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:07:52 -0000

Hi All, 

I'm in favour of option 2 as well.

I'd like to note that there are other drafts in ccamp that may be affected
by this change:
- draft-galikunze-ccamp-g-698-2-snmp-mib
- draft-dharinigert-ccamp-g-698-2-lmp
- draft-dharini-netmod-g-698-2-yang

I'm co-author of them and as such I'll coordinate with the other authors
to fix the drafts.

Best Regards, 


Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy <>
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

On 1/29/15 2:23 PM, "Adrian Farrel" <> wrote:

>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
>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?
>> several choices each vendor may support in its device, the path
>> would find a matched types for FEC and modulation for a given optical
>> This is what is intended when optical signal processing constraints
>> 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.
>CCAMP mailing list