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

Shane Amante <shane@castlepoint.net> Mon, 06 December 2010 20:20 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 8CE0E3A68B3 for <isis-wg@core3.amsl.com>; Mon, 6 Dec 2010 12:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 PfBm9SnLjrjM for <isis-wg@core3.amsl.com>; Mon, 6 Dec 2010 12:20:35 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 609653A6895 for <isis-wg@ietf.org>; Mon, 6 Dec 2010 12:20:35 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 3E4C126866A; Mon, 6 Dec 2010 13:21:59 -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 13:21:59 -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=63021; 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: <AE36820147909644AD2A7CA014B1FB520CBA0737@xmb-sjc-222.amer.cisco.com>
Date: Mon, 06 Dec 2010 13:21:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <309BCE56-9213-4B29-A364-B3421D952080@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>
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 20:20:36 -0000

Les,

On Dec 6, 2010, at 09:51 MST, Les Ginsberg (ginsberg) wrote:
> What we agree on is the need for a new tool (advertise non-zero cost in
> pseudo-node LSPs) to assist in making LAN maintenance easier (albeit
> this has some risks as you have highlighted in your survey).

OK.


> What we don't agree on is that the convenience of being able to go to
> Node A and issue command(s) which make the necessary temporary config
> changes (as opposed to going to Node A and B) justifies the introduction
> of the Reverse Metric TLV and its associated complexities.

With all due respect, it sounds like you may not appreciate the size/class of networks we run today.  :-)  

Over the last several years, we (and other SP's) have been deploying multi-Terabit class routers, (i.e.: no "marketing math" <ahem>).  Each of these have onboard several hundred high-speed interfaces _each_.  You're asserting that it's easier, on a _daily_ basis, for me and other SP's to:
a)  accurately identify the same [point-to-point] interface on two, separate routers (again, w/ hundreds of interfaces apiece) at 3AM in the morning;
b)  remember/write-down the existing IS-IS metric that was configured *before* I begin the maintenance;
c)  change the metric (on both sides) to isolate the link/LAN; and,
d)  back out the above changes, at a similar unholy hour of the morning?

And, we wonder why the Internet is only perceived as a "best-effort" network?


On a more serious note, it's important to recognize that in order to mitigate human-error, we need to reduce the burden on operators to "always get it right", as you seem to imply above, and certainly as our executives (and customers) want us to.  Codifying something like the Reverse Metric TLV in the protocol allows operators to have a _repeatable_, interoperable mechanism that will dramatically reduce the risk of 'human error' for a widely accepted & used operational practice (link isolation).  Given that all public studies I've seen classify 'human error' as the dominant cause of network outages, one would think we should be looking at ways to remedy that ...

-shane