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

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 02 February 2015 18:06 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03B01A882E for <ccamp@ietfa.amsl.com>; Mon, 2 Feb 2015 10:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drrO5DmtMmQE for <ccamp@ietfa.amsl.com>; Mon, 2 Feb 2015 10:06:43 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DE21A8825 for <ccamp@ietf.org>; Mon, 2 Feb 2015 10:06:43 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t12I6Rx5010617; Mon, 2 Feb 2015 18:06:27 GMT
Received: from 950129200 (089144215032.atnat0024.highway.a1.net [89.144.215.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t12I6MLI010547 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2015 18:06:23 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Leeyoung'" <leeyoung@huawei.com>, "'Daniele Ceccarelli'" <daniele.ceccarelli@ericsson.com>, "'Varma, Eve L \(Eve\)'" <eve.varma@alcatel-lucent.com>, <db3546@att.com>, "'Lam, Hing-Kam \(Kam\)'" <kam.lam@alcatel-lucent.com>, <ggrammel@juniper.net>, <giomarti@cisco.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F587@dfweml706-chm> <4A1562797D64E44993C5CBF38CF1BE481284FFD2@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C7FF70@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7FF70@dfweml706-chm>
Date: Mon, 2 Feb 2015 18:06:21 -0000
Message-ID: <00f901d03f12$f63c69e0$e2b53da0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJJUQOjjDfAQ8oFRmu1FlrhpmJTlQFT1EnjAetg4z8CJ7+qqAFLKtJcAmMyN0sB/zHu9gFYnHWom4ganBA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21300.001
X-TM-AS-Result: No--25.938-10.0-31-10
X-imss-scan-details: No--25.938-10.0-31-10
X-TMASE-MatchedRID: oll/cJ/dUC6nykMun0J1wuJ28KqpjndpcmsHQK7cMOfadW4iYSMjUfIL 3EilQkpCNmGpMRurlIK315zkSkPtdwHu7QwNULrhlVHM/F6YkvT2X2nyY2WSCSJlFuUUbH7wrDB 5BBSv7xA6R+gJS2GFRXbkEFG5UWmnmZGvWTp76WAIVoCLGbl5T5E+3DCX3uibWltirZ/iPP6gyH v1XdDY+crcmjuqhtuSiLY1K/aKw9Owk2ceO9w6iRz2MDiYujy5RJK67OhGmkPNQVzhfYY5sp2si kM5aAK7D4wrWfDTPuzANNz/A2ARw6c9Vc+Sj66qmAafP3c9X3fF0gM0Cl6pKwzvg1/q1MH2RFc/ MwCIIKW0W1cvADA9Cg96TMM5I2h03iRA5D6hwxOn1yJegn+layOjxzQ2RhgiWP9qYuzytBLasx+ ynSfOhM3qYFWyEE/cBE9uOw8WedjLz1mIn0LQ/R3EEAbn+GRbyeUl7aCTy8ghvFjBsLEZNJ6KJF ezorzrXC+Mm/m42Ntxo5IJvKByVaX2s5Nec6il4T0EFRcNxxTWSrKtwxqWpZS9f9yLlOOyBOgCo Vs10LMBN3tZtorirvSa76bMXYl4aOHd6Wm/K5RYPoKcu56ctTqu3dM+YhFRzhY2/o0jwSQyFvuX t08oHwIeZXWczlrTtHXKH8r2o51FeTvsZXlu3am4PbloS2C3+KgiyLtJrSCyd65qZFFPkzpbfdT AcNXm4vM1YF6AJbbYb8xKuOetqVZ0V5tYhzdWxEHRux+uk8jpP8tMOyYmaA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/yyDgrtPFAC5-zd8c1gpxJ3DJ7d8>
Cc: paul.doolan@coriant.com, ccamp@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 18:06:50 -0000

Thanks all.

In my opinion we have converged enough on all of the review points for Young to
post a new version and for us to move it forwards.

Adrian

> -----Original Message-----
> From: Leeyoung [mailto:leeyoung@huawei.com]
> Sent: 02 February 2015 15:38
> To: Daniele Ceccarelli; adrian@olddog.co.uk; 'Varma, Eve L (Eve)';
> db3546@att.com; 'Lam, Hing-Kam (Kam)'; ggrammel@juniper.net;
> giomarti@cisco.com
> Cc: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-chairs@tools.ietf.org;
> draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
> Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-
> wson-encode
> 
> Hi Daniele and Fatai,
> 
> Thanks for the resolution. I am still waiting for Adrian's other comments (as
part
> of the AD review) and comments from ITU-T Q6/15 on the Application Codes.
> Once they are resolved, a revision will be made available.
> 
> Regards,
> Young
> 
> -----Original Message-----
> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> Sent: Monday, February 02, 2015 4:14 AM
> To: Leeyoung; adrian@olddog.co.uk; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam,
> Hing-Kam (Kam)'; ggrammel@juniper.net; giomarti@cisco.com
> Cc: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-chairs@tools.ietf.org;
> draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
> Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-
> wson-encode
> 
> Working group,
> 
> It seems there is a strong willingness to support Vendor Specific Application
> Codes (a.k.a Option 2).
> 
> This would require putting the draft on hold till the formal approval of
G.874.1
> (should be July 2015), but we would like not to stop the draft for so long
since a
> lot of other contents are ready to be progressed.
> 
> Our proposal is to move on with option 3 (i.e. Remove the option to include a
> Vendor-Specific Application Code field.) and add the support for vendor
specific
> application codes later in a BIS or a small, simple and straightforward draft
as soon
> as G.874.1 is approved.
> 
> Young, authors, please update the draft accordingly and maybe add a note
saying
> that  "future work may add support for vendor-specific AI once the ITU-T has
> completed its work in that area"
> 
> Working group, who would find it impossible to live with this as a compromise
> approach? If you cannot live with this approach, please explain why.
> 
> BR
> Daniele & Fatai
> 
> 
> 
> 
> > -----Original Message-----
> > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Leeyoung
> > Sent: giovedì 29 gennaio 2015 20:11
> > To: adrian@olddog.co.uk; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam,
> > Hing-Kam (Kam)'; ggrammel@juniper.net; giomarti@cisco.com
> > Cc: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-
> > chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
> > Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-
> > rwa-wson-encode
> >
> > Hi Adrian,
> >
> > I think you misinterpreted what was said.
> >
> > >> 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.
> >
> > The standard AI allows to match optical processing constraints (including
> > FECs and Modulations implied in an AI). This information is advertised that
a
> > PCE would be able to compute an optical path matching AIs for all the
> > devices to dertermine a feasible path. I am talking about this standard
> > control plane work. This is what was intended in the draft.
> >
> > Regards,
> > Young
> >
> > -----Original Message-----
> > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > Sent: Thursday, January 29, 2015 7:24 AM
> > To: Leeyoung; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, Hing-Kam
> > (Kam)'; ggrammel@juniper.net; giomarti@cisco.com
> > Cc: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-
> > chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
> > 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@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp