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, 02 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
- [CCAMP] Vendor-Specific Application Code in draft… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lam, Hing-Kam (Kam)
- Re: [CCAMP] Vendor-Specific Application Code in d… Gert Grammel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lam, Hing-Kam (Kam)
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lam, Hing-Kam (Kam)
- Re: [CCAMP] Vendor-Specific Application Code in d… BRUNGARD, DEBORAH A
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… BRUNGARD, DEBORAH A
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Varma, Eve L (Eve)
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Doolan, Paul (Coriant - US/Irving)
- Re: [CCAMP] Vendor-Specific Application Code in d… Fatai Zhang
- Re: [CCAMP] Vendor-Specific Application Code in d… Dieter Beller
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Huub van Helvoort
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Gert Grammel
- Re: [CCAMP] Vendor-Specific Application Code in d… Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] Vendor-Specific Application Code in d… Zhangxian (Xian)
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Daniele Ceccarelli
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel
- Re: [CCAMP] Vendor-Specific Application Code in d… Lou Berger
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Daniele Ceccarelli
- Re: [CCAMP] Vendor-Specific Application Code in d… Leeyoung
- Re: [CCAMP] Vendor-Specific Application Code in d… Adrian Farrel