Re: [Isis-wg] draft-amante-isis-reverse-metric-01

Shane Amante <shane@castlepoint.net> Mon, 06 December 2010 22:22 UTC

Return-Path: <shane@castlepoint.net>
X-Original-To: isis-wg@core3.amsl.com
Delivered-To: isis-wg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B563A68D4 for <isis-wg@core3.amsl.com>; Mon, 6 Dec 2010 14:22:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOkocf94Qnyc for <isis-wg@core3.amsl.com>; Mon, 6 Dec 2010 14:22:04 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 79EF63A68D0 for <isis-wg@ietf.org>; Mon, 6 Dec 2010 14:22:04 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id A2DD926866A; Mon, 6 Dec 2010 15:23:28 -0700 (MST)
Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 06 Dec 2010 15:23:28 -0700 (MST) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=64086; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520CC3F70E@xmb-sjc-222.amer.cisco.com>
Date: Mon, 06 Dec 2010 15:23:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E043F80D-6982-4480-8C65-BB6D65DADAE5@castlepoint.net>
References: <C9F49613-1F78-484A-B7D3-7E4028E0B9C3@castlepoint.net> <AE36820147909644AD2A7CA014B1FB520CBA0665@xmb-sjc-222.amer.cisco.com> <2EEE5586-CD41-4C13-8D13-FC69ED126A1F@castlepoint.net> <AE36820147909644AD2A7CA014B1FB520CBA0737@xmb-sjc-222.amer.cisco.com> <309BCE56-9213-4B29-A364-B3421D952080@castlepoint.net> <AE36820147909644AD2A7CA014B1FB520CC3F70E@xmb-sjc-222.amer.cisco.com>
To: Les Ginsberg <ginsberg@cisco.com>
X-Mailer: Apple Mail (2.1082)
Cc: isis mailing list <isis-wg@ietf.org>
Subject: Re: [Isis-wg] draft-amante-isis-reverse-metric-01
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Dec 2010 22:22:05 -0000

Les,

On Dec 6, 2010, at 14:47 MST, Les Ginsberg (ginsberg) wrote:
> Just because I am pushing for doing this via local config and against
> via a protocol extension does not mean that I am against the concept of
> a temporary metric change. You are asking implementations to support the
> idea of a temporary change to the currently advertised mettric w/o
> altering the saved configuration. This certainly can be done w/o
> extending the protocol - so there is no need to "remember/write-down the
> existing IS-IS metric that was configured *before* I begin the
> maintenance". You would simply remove the temporary config and the
> router would automatically revert to the saved config. Internally this
> has to be done regardless of whether you use the TLV or not.

It sounds to me like you're unwilling to consider (or, acknowledge?) that the primary reason for the Reverse Metric draft is to solve for deterministic isolation of point-to-point interfaces, which is the dominant link type in the network.  Is this a fair assessment?

-shane


> At the risk of repeating myself (again!!) I would emphasize the only
> difference between what you want and what I want is whether it requires
> a protocol extension to do it - we aren't disagreeing on the
> functionality that is desirable.