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

Huub van Helvoort <> Thu, 29 January 2015 13:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A861D1A0636 for <>; Thu, 29 Jan 2015 05:49:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D1e3SS9P7hGR for <>; Thu, 29 Jan 2015 05:49:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BAC31A038A for <>; Thu, 29 Jan 2015 05:49:15 -0800 (PST)
Received: by with SMTP id r20so26566438wiv.0 for <>; Thu, 29 Jan 2015 05:49:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=s74ZDgkzKWuMB6PdLYjbHLF0ux9w9F4ireM4r0WmWDk=; b=nXBQLUVv0haHnjqff6ey5lENzlnJS+lV+ebOe8HCkwLO+vgkjjYz+YAIWWKuWuAUjv rQqGmhzd00/JFi64oY/R3jm1iBpzovJIKihzabXZnrjFLhhkPJvOGOxryfPRzjH3He6R B8I712i57Bt1f03WmfyNDOElfWBJqvvTIpI3Y9Mbi6rt5/mfM5V1/RHPsc/LXhPoNh0c KEmRf6QRRJkn/ITHCmJ1Oi7XgyC1UDIAVh6a9WdLsTwzAhbG3veEs5hZbQXf3rDMakp7 FCS2B1PmmiVT1bWiiTsg5CHVId7GQgEWy0srFIOJ7YUskYfGa3NeBuh0huLmSAClofqh iXuQ==
X-Received: by with SMTP id pe9mr192839wic.13.1422539354316; Thu, 29 Jan 2015 05:49:14 -0800 (PST)
Received: from McObelix.local ( []) by with ESMTPSA id fi10sm2558126wib.13.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 05:49:13 -0800 (PST)
Message-ID: <>
Date: Thu, 29 Jan 2015 14:49:12 +0100
From: Huub van Helvoort <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To:, 'Leeyoung' <>
References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <> <086901d03b3a$c7386c10$55a94430$> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$>
In-Reply-To: <00ff01d03bc6$d84bbcf0$88e336d0$>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
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 13:49:21 -0000


I agree with Adrians assessment.

+1 for option 2.

Regards, Huub.

On 29-01-15 14:23, 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 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