Re: [Gen-art] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 08 September 2015 16:01 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CDF1ACEAC; Tue, 8 Sep 2015 09:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.701
X-Spam-Level:
X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 v6FJYzD8hkFq; Tue, 8 Sep 2015 09:01:55 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87EE1A01D5; Tue, 8 Sep 2015 09:01:51 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t88G1l9l021345; Tue, 8 Sep 2015 17:01:48 +0100
Received: from 950129200 ([62.7.67.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t88G1f4Z021259 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2015 17:01:46 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Daniele Ceccarelli' <daniele.ceccarelli@ericsson.com>, 'Adrian Farrel' <afarrel@juniper.net>, 'Robert Sparks' <rjsparks@nostrum.com>, draft-ietf-ccamp-flexigrid-lambda-label@ietf.org, ccamp@ietf.org, 'General Area Review Team' <gen-art@ietf.org>, ietf@ietf.org
References: <55E75637.9030800@nostrum.com> <4A1562797D64E44993C5CBF38CF1BE48129EAC0C@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48129EAC0C@ESESSMB301.ericsson.se>
Date: Tue, 08 Sep 2015 17:01:41 +0100
Message-ID: <01cf01d0ea4f$aa4ddd50$fee997f0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF9i09QW/wkh4JgboaEl6Ud5RBjlQK+QpaqnsOUoSA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21804.000
X-TM-AS-Result: No--10.643-10.0-31-10
X-imss-scan-details: No--10.643-10.0-31-10
X-TMASE-MatchedRID: VfovoVrt/oY4HKI/yaqRm+YAh37ZsBDCQV6BZJ9WeFbSYAzZ6KmqWlTY GusIwRcJ/8dwTppjCkZLnfhG6AojyRZth7gGVYH2W7gz/Gbgpl7yoHHk1agFzbkiJ/BgvX6rbzX zPWymwLkT+KeB7bRhwXUF/sNfMS7WtAxtk7pRcd7cWo5Vvs8MQgpqOIpWiKGpVv+3DNSQobNxEW 0uzmaRA8wiPFwdmGtzDHUYwes5GeYgTx1R9EMDmDDfgfM3Zc/RFJFr2qlKix8dY1owGR6BJ/pZj WQiqBlhN0q3D0fzPh+kyVAIR7WdwOVHGbcDbAq6gxsfzkNRlfLdB/CxWTRRu25FeHtsUoHuMLny /eSDRsPwyPc9othGlxgF7Qm6z8BSM61556XL364JK2MK45H+GA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/6eiD545UK9oibcttwREa-ghTkAU>
Subject: Re: [Gen-art] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2015 16:01:57 -0000

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