Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04
Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Wed, 09 September 2015 09:00 UTC
Return-Path: <daniele.ceccarelli@ericsson.com>
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 ACBD51A897E; Wed, 9 Sep 2015 02:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 6TgWb5SstEsZ; Wed, 9 Sep 2015 02:00:35 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F56E1A896A; Wed, 9 Sep 2015 02:00:34 -0700 (PDT)
X-AuditID: c1b4fb25-f79a26d00000149a-46-55eff530d491
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.1B.05274.035FFE55; Wed, 9 Sep 2015 11:00:32 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.27]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Wed, 9 Sep 2015 11:00:31 +0200
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "julien.meuric@orange.com" <julien.meuric@orange.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Adrian Farrel' <afarrel@juniper.net>, 'Robert Sparks' <rjsparks@nostrum.com>, "draft-ietf-ccamp-flexigrid-lambda-label@ietf.org" <draft-ietf-ccamp-flexigrid-lambda-label@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, 'General Area Review Team' <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [CCAMP] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04
Thread-Index: AQHQ6kUGZMXJzVccMUaiX0cWQUZ3i54yqTuAgAEnDbD///NigIAAIzmQ
Date: Wed, 09 Sep 2015 09:00:31 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE48129EB052@ESESSMB301.ericsson.se>
References: <55E75637.9030800@nostrum.com> <4A1562797D64E44993C5CBF38CF1BE48129EAC0C@ESESSMB301.ericsson.se> <01cf01d0ea4f$aa4ddd50$fee997f0$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48129EAF51@ESESSMB301.ericsson.se> <5182_1441788754_55EFF352_5182_75_2_55EFF351.2080302@orange.com>
In-Reply-To: <5182_1441788754_55EFF352_5182_75_2_55EFF351.2080302@orange.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3Rtfg6/tQg5Z9EhY/em4wW0x8cZ/J 4smcGywWi/Y/YrK4+uozi8WzjfNZLP6c/stkcW1OI5sDh8eSJT+ZPK43XWX3mLXzCYvHis0r GT1anp1kC2CN4rJJSc3JLEst0rdL4Mp40zKLvWCRXcWUqQdZGhiv2HQxcnJICJhIvL27ihHC FpO4cG89WxcjF4eQwFFGiUWr/0I5ixgl7n/fxt7FyMHBJmAl8eSQD0hcRGA2s8SF5odMIN3C AiESS682g9kiAqES5x4dZ4Sw3SROnd0HZrMIqEgc+PKABcTmFfCVeHbqLzvEgmVMEpcPXwNr 5gRKrP8ykw3EZhSQlZiwexFYM7OAuMStJ/OZIE4VkFiy5zwzhC0q8fLxP1YIW1Hi4yuQZRxA 9ZoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCyrGIULU4tTspNNzLW Sy3KTC4uzs/Ty0st2cQIjMCDW36r7mC8/MbxEKMAB6MSD+/CSe9DhVgTy4orcw8xSnOwKInz NjM9CBUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWOUZUNpY3iMfsyroodX/o/MK/Lx2qThP Ya+ZcOLpvL97NhUw1ux3FQ19xq206ci5ax2TtyQc3XT7lvIMt7WLXhTMt9ra2J/+5mvU4duL vENWtqm8OFcjNOcV3/X1W9aumsUYHfX5x/yr05Pl9E5XbP1/xSztpBi3oxFzReJ2qSVe2yz6 /i3b9leJpTgj0VCLuag4EQCxhHBxoQIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/nLKxhbG0k2iR9Siewd4qasIBWlU>
Subject: Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 09 Sep 2015 09:00:37 -0000
Hi Julien, Thanks for providing and operator point of view and for proving I'm wrong :) We have one more reason to update the draft with the backward compatibility statements then. Thanks a lot, Daniele > -----Original Message----- > From: julien.meuric@orange.com [mailto:julien.meuric@orange.com] > Sent: mercoledì 9 settembre 2015 10:53 > To: Daniele Ceccarelli; adrian@olddog.co.uk; 'Adrian Farrel'; 'Robert Sparks'; > draft-ietf-ccamp-flexigrid-lambda-label@ietf.org; ccamp@ietf.org; 'General > Area Review Team'; ietf@ietf.org > Subject: Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda- > label-04 > > Ciao Daniele. > > SP's hat on, I need to disagree with you there. > > What Adrian proposes allows me to add new pieces of equipment to address > traffic needs, without waiting for an NMS release supporting 100% of the > feature I use. In this situation, I can choose between upgrading or waiting for > the full package alignment: it remains my call, on a case by case basis. The > wording also emphasizes the generalized beauty of GMPLS: > new label encodings should not prevent the management of other protocol > aspects ("be liberal in what you accept...). > > What you suggest would prohibit that scenario, i.e., I need wait for fully- > featured NMS, whatever the network is capable of. This is sometimes not > acceptable: service needs prevail on fully detailed management, the NMS > should not be a network limitation. The current example, where label > resolution could rely on a (temporary?) external tool, makes it even more > realistic. > > Regards, > > Julien > > > Sep. 09, 2015 - daniele.ceccarelli@ericsson.com: > > Hi Adrian, > > > > I tend disagree with this statement: > > > > "My contention is that it is quite likely that someone would try to use a > legacy NMS to manage a new flexigrid network since "it is all just GMPLS". > And it is not an unreasonable assumption to be able to do this if some fields > (for example, label) can be displayed as opaque quantities." > > > > I'm not sure an operator would be happy to see 96 channels called > lambda1, lambda2,..., lambda 96 from his NMS while the network is flexi > grid. > > We'll have to face these issues when we'll be speaking about YANG models > for flexi grid but for the time being let's be on the safe side and address the > compatibility issue as you're suggesting. > > > > Cheers, > > Daniele > > > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: martedì 8 settembre 2015 18:02 > >> > >> Hi Daniele, > >> > >>> Thanks for the careful review and your comments. > >>> I pretty much agree with Adrian's reply but I think explicitly > >>> having some backward compatibility text in the draft could be helpful. > >>> > >>> Adrian, authors, I'd suggest changing section 5 from "Manageability > >>> Considerations" to "Backward Compatibility and Manageability > >> Considerations" > >>> adding to the existing text backward compatibility considerations > >>> against legacy GMPLS and legacy NMS (mostly what you've already > >>> written > >> below). > >> > >> I can work on this. > >> > >>> WRT the legacy NMS I don't think it is a reasonable scenario, since > >>> before operating the nodes with a GMPLS implementing this draft, the > >>> node needs to be configured and the NMS must be flexi-grid compatible. > >> > >> But wait! This is exactly the point. > >> Suppose there is an NMS that is inspecting an LSP at a transit node. > >> That NMS does not need to be flexigrid compatible to read the details > >> of the LSP at that transit node. > >> However, it *does* need to have some capabilities in order to not > >> barf when it gets the response from the LSR. > >> The first thing is to handle a 64 bit label as an opaque string. > >> The advanced thing is to be able to parse out the 64 bits into the > >> relevant fields. > >> > >> Indeed, to request the setup of a flexigrid LSP does not require a > >> flexigrid compatible NMS since it is possible to simply request a > >> path and bandwidth (or not even request a path). > >> > >> My contention is that it is quite likely that someone would try to > >> use a legacy NMS to manage a new flexigrid network since "it is all > >> just GMPLS". And it is not an unreasonable assumption to be able to > >> do this if some fields (for example, label) can be displayed as opaque > quantities. > >> > >> Now, if you are talking about an EMS, I completely agree. > >> > >> Cheers, > >> Adrian > >> > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > ______________________________________________________________ > ___________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you.
- [CCAMP] Gen-art LC review: draft-ietf-ccamp-flexi… Robert Sparks
- Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-f… Adrian Farrel
- Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-f… Daniele Ceccarelli
- Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-f… Adrian Farrel
- Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-f… Daniele Ceccarelli
- Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-f… julien.meuric
- Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-f… Daniele Ceccarelli
- [CCAMP] Gen-art Telechat review: draft-ietf-ccamp… Robert Sparks
- Re: [CCAMP] [Gen-art] Gen-art Telechat review: dr… Jari Arkko