IETF Logo Mail Archive

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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 06 December 2010 08:42 UTC

Return-Path: <ginsberg@cisco.com>
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 071753A6A25 for <isis-wg@core3.amsl.com>; Mon, 6 Dec 2010 00:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.269
X-Spam-Level:
X-Spam-Status: No, score=-9.269 tagged_above=-999 required=5 tests=[AWL=1.330, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 hra5S18ZYB99 for <isis-wg@core3.amsl.com>; Mon, 6 Dec 2010 00:42:48 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0C5A63A69FD for <isis-wg@ietf.org>; Mon, 6 Dec 2010 00:42:48 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAB4x/EyrR7Ht/2dsb2JhbACjMXGiKZo0hUkEhF+JKA
X-IronPort-AV: E=Sophos;i="4.59,305,1288569600"; d="scan'208";a="295807293"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 06 Dec 2010 08:44:11 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oB68iB3s005093; Mon, 6 Dec 2010 08:44:11 GMT
Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Dec 2010 00:44:11 -0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 06 Dec 2010 00:44:09 -0800
Message-ID: <AE36820147909644AD2A7CA014B1FB520CBA067C@xmb-sjc-222.amer.cisco.com>
In-Reply-To: <EDF54BC9-7AF6-4094-AA4C-2264CEE0D691@tony.li>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Isis-wg] draft-amante-isis-reverse-metric-01
Thread-Index: AcuVH+LZ7zauKs+hT/GktMZmZPR3IgAAI98g
References: <C9F49613-1F78-484A-B7D3-7E4028E0B9C3@castlepoint.net><AE36820147909644AD2A7CA014B1FB520CBA0665@xmb-sjc-222.amer.cisco.com><85B48966-02C4-47A3-A108-81D7A2B32424@tony.li><AE36820147909644AD2A7CA014B1FB520CBA0676@xmb-sjc-222.amer.cisco.com> <EDF54BC9-7AF6-4094-AA4C-2264CEE0D691@tony.li>
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Tony Li <tony.li@tony.li>
X-OriginalArrivalTime: 06 Dec 2010 08:44:11.0111 (UTC) FILETIME=[C0C9EF70:01CB9521]
Cc: Shane Amante <shane@castlepoint.net>, 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 08:42:49 -0000

Tony -

I honestly don't understand your comment below. 
I started this new thread by summarizing how one could achieve the
desired functionality with or without the Reverse Metric TLV.

<snip>
Without Reverse Metric TLV: On the DIS must configure max metric to be
sent in p-node LSP on the DIS for the neighbor(s) of interest (or ALL
neighbors)

With Reverse Metric: Must configure the reverse metric to be sent to the
DIS on each neighbor of interest - or in the case of impacting ALL
neighbors the reverse metric config an be done on any neighbor (DIS or
non-DIS)

The difference is then whether the config change MUST be done on the DIS
or may be done on any neighbor on the LAN.
<end snip>

I am not suggesting a "workaround" - I am pointing out that you can use
local config to achieve the same functionality. I am also pointing out
that configuration-wise this is not any more onerous than the
configuration required to specify the use of reverse-metric TLV. I am
also pointing out that using local config avoids:

1)Introduction of new TLV support
2)Requirement to handle competing advertisements from multiple neighbors
3)Requirement to support "block reverse TLV usage" configuration

We are both headed in the same direction i.e. provide a new tool by
supporting non-zero metric in pseudo-node LSPs. The issue that remains
is how to configure support for this. I don't see how what is proposed
in draft-shen-isis-oper-enhance (which I support) is more complex than
reverse metric TLV - in fact I think the opposite is the case.

   Les


> -----Original Message-----
> From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On
> Behalf Of Tony Li
> Sent: Monday, December 06, 2010 12:30 AM
> To: Les Ginsberg (ginsberg)
> Cc: Shane Amante; isis mailing list
> Subject: Re: [Isis-wg] draft-amante-isis-reverse-metric-01
> 
> 
> Les,
> 
> Aren't we supposed to be making it easier to operate a network?  It
> seems like adding 'workarounds' is the wrong direction: you're adding
> complexity to operations in conjunction with the requested
> functionality.
> 
> Tony
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg

v2.23.0 | Report a Bug | By Email