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

Gert Grammel <> Thu, 29 January 2015 16:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 584AE1A1EEA for <>; Thu, 29 Jan 2015 08:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nAx50r7DW7AB for <>; Thu, 29 Jan 2015 08:00:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 789F81A1AF0 for <>; Thu, 29 Jan 2015 08:00:11 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 29 Jan 2015 16:00:04 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 29 Jan 2015 16:00:02 +0000
Received: from ([]) by ([]) with mapi id 15.01.0065.013; Thu, 29 Jan 2015 16:00:02 +0000
From: Gert Grammel <>
To: "" <>, 'Leeyoung' <>, "'Varma, Eve L (Eve)'" <>, "" <>, "'Lam, Hing-Kam (Kam)'" <>, "" <>
Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
Date: Thu, 29 Jan 2015 16:00:02 +0000
Message-ID: <>
References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <> <086901d03b3a$c7386c10$55a94430$> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$>
In-Reply-To: <00ff01d03bc6$d84bbcf0$88e336d0$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN1PR05MB043; UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB043;
x-forefront-prvs: 0471B73328
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(2900100001)(93886004)(102836002)(230783001)(2501002)(66066001)(92566002)(46102003)(76576001)(74316001)(15975445007)(2950100001)(19580405001)(2656002)(87936001)(62966003)(54606007)(76176999)(40100003)(122556002)(54206007)(50986999)(99286002)(106116001)(54356999)(77156002)(33656002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB043;; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2015 16:00:02.5883 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB043
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB041;
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:00:24 -0000

Hi Leeyoung, 

Keep in mind that G.698.2 allows to use transceivers from different vendors, based on standard AIs (=Application Codes). Now in case of a multi-vendor network, *additional* proprietary application codes can be used if there is a pre-knowledge that the proprietary AIs match. I believe this was one case you were referring to.
So a single transceiver HW implementation supporting the standard-AI will almost certainly support also a vendor-AI e.g.,  if a higher level of OSNR can be tolerated than the standard-AI has encoded. Hence we can conclude that a single (vendor) transceiver potentially supports a list of AIs. So even by picking Option 2 your case can be addressed.

How to encode those AIs is another matter as printable strings are not always the best choice to use. and already provide some encoding, whereby OUI would need to be worked in.


-----Original Message-----
From: Adrian Farrel [] 
Sent: 29 January 2015 14:24
To: 'Leeyoung'; 'Varma, Eve L (Eve)';; 'Lam, Hing-Kam (Kam)'; Gert Grammel;
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.