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

"Adrian Farrel" <> Thu, 29 January 2015 13:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B701F1A036C for <>; Thu, 29 Jan 2015 05:24:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zWawX1Y06fSG for <>; Thu, 29 Jan 2015 05:24:46 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3C831A037E for <>; Thu, 29 Jan 2015 05:24:45 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id t0TDO28w000786; Thu, 29 Jan 2015 13:24:02 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t0TDO0BU000776 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2015 13:24:00 GMT
From: "Adrian Farrel" <>
To: "'Leeyoung'" <>, "'Varma, Eve L \(Eve\)'" <>, <>, "'Lam, Hing-Kam \(Kam\)'" <>, <>, <>
References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <> <086901d03b3a$c7386c10$55a94430$> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm>
Date: Thu, 29 Jan 2015 13:23:59 -0000
Message-ID: <00ff01d03bc6$d84bbcf0$88e336d0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJJUQOjjDfAQ8oFRmu1FlrhpmJTlQFT1EnjAetg4z8CJ7+qqJu5sV6g
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--2.376-10.0-31-10
X-imss-scan-details: No--2.376-10.0-31-10
X-TMASE-MatchedRID: hls5oAVArl84HKI/yaqRm0hEDfw/93BulnrMq7Sriu1uSX0LjRs5dfF1 IdU1dF/S93WdQoPE0d1hjPrPq/NtUxaadt99xiokJXKk/roE/RCPmFSaq6xM+GXczQlokCRZq+1 liYblo0L9VVCUNaKG6vYx6jUoivPIJtllgBC70fncWo5Vvs8MQpWr6iSXWtgPd71AOvz4tNx4lf x9oG1pi6NmZd67d7ssYMSJm0fVeNVbgcVfm+q5rI4V8tCoXo/SgdNXa4lpKNvJYIv7y0tu9jIW+ 5e3TygfAh5ldZzOWtO0dcofyvajnUV5O+xleW7dngIgpj8eDcByZ8zcONpAscRB0bsfrpPInxMy eYT53Rmgtni9Z1tMQQYbuTsOs7wqvdmOeyS992DG+5f3ulbfN6MSQ2p5W2Xbr3l36Qwm9rWTO6A CM932trpuFii4t6mcM4eY+qoaMQPEKh5bR1PYFof8kK+K1APpIcrpoIxNunWiPKQz22GTEVZca9 RSYo/b
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:24:53 -0000

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.