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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 06 December 2010 07:58 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 4F8AD3A69C6 for <isis-wg@core3.amsl.com>; Sun, 5 Dec 2010 23:58:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.121
X-Spam-Level:
X-Spam-Status: No, score=-9.121 tagged_above=-999 required=5 tests=[AWL=1.478, 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 DaFfjUkmAcOk for <isis-wg@core3.amsl.com>; Sun, 5 Dec 2010 23:57:59 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 285193A69FB for <isis-wg@ietf.org>; Sun, 5 Dec 2010 23:57:59 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEABom/EyrR7Ht/2dsb2JhbACjMHGiF5owhUkEhF+JKA
X-IronPort-AV: E=Sophos;i="4.59,305,1288569600"; d="scan'208";a="631422071"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 06 Dec 2010 07:59:22 +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 oB67xM3d006617; Mon, 6 Dec 2010 07:59:22 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); Sun, 5 Dec 2010 23:59:22 -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: Sun, 05 Dec 2010 23:59:20 -0800
Message-ID: <AE36820147909644AD2A7CA014B1FB520CBA0676@xmb-sjc-222.amer.cisco.com>
In-Reply-To: <85B48966-02C4-47A3-A108-81D7A2B32424@tony.li>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Isis-wg] draft-amante-isis-reverse-metric-01
Thread-Index: AcuVGO8qMJPRndx+QduqvyeD+MZECgAACwWQ
References: <C9F49613-1F78-484A-B7D3-7E4028E0B9C3@castlepoint.net> <AE36820147909644AD2A7CA014B1FB520CBA0665@xmb-sjc-222.amer.cisco.com> <85B48966-02C4-47A3-A108-81D7A2B32424@tony.li>
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Tony Li <tony.li@tony.li>
X-OriginalArrivalTime: 06 Dec 2010 07:59:22.0164 (UTC) FILETIME=[7E0D2F40:01CB951B]
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 07:58:00 -0000

Tony -

> -----Original Message-----
> From: Tony Li [mailto:tony.li@tony.li]
> Sent: Sunday, December 05, 2010 11:41 PM
> To: Les Ginsberg (ginsberg)
> Cc: Shane Amante; isis mailing list
> Subject: Re: [Isis-wg] draft-amante-isis-reverse-metric-01
> 
> 
> Hi Les,
> 
> > Multi-Access LANs
> > -----------------
> >
> > 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)
> 
> 
> In fact, without the reverse metric TLV, you cannot do this at all.
> Without extending the protocol is _some_ way, you are not allowed to
> have a non-zero metric in the pseudonode.  Further, Shane's survey
> suggests that there is sufficient variation in implementations that it
> is unsafe to advertise a non-zero pseudonode metric without some flag
> day for the domain anyway.

The "extension" is - as you say - the use of non-zero metric in the
pseudonode LSP. This does not, however, imply that we need the Reverse
Metric TLV. It is a question of how you signal the DIS to advertise the
non-zero metric. That can be done by local configuration on the DIS.
This is discussed in  draft-shen-isis-oper-enhance - and there it is
pointed out that one can temporarily make any given the node the DIS by
changing LAN priority - so if finding the DIS is the onerous task this
can be worked around.

Everything you want to do can be done without the Reverse Metric TLV -
and the risks are the same. However this is signaled (local config or
Reverse Metric TLV) so long as the DIS supports the new functionality,
it is possible to start advertising non-zero metrics in pseudo-node LSPs
without knowing whether all ISs in the domain support this extension or
not.

The ability to override local configuration via information advertised
by your neighbor introduces a management application capability into the
routing protocol itself - and also introduces additional complexities.
These complexities include handling competing advertisements from
multiple neighbors and supporting configuration to block the use of
reverse metric TLV - both of which are discussed in the draft. If we
never introduce the Reverse Metric TLV we can still do everything that
is required and we do not have to introduce a new TLV nor deal with
these problematic cases.

I think draft-shen-isis-oper-enhance is quite sufficient and there is no
need for the Reverse Metric TLV.

   Les


> 
> 
> > Frankly, I am not seeing this benefit as very compelling. The big
win
> on
> > the LAN is the introduction of the ability to use something other
> than 0
> > in the pseudo-node LSPs - and that can be done (with the same amount
> of
> > risk) without the Reverse Metric TLV by configuring it on the DIS.
> 
> 
> The ability to make one link of an L2 switching domain into a link of
> last resort seems like it is compelling to me, and the ability to do
so
> from the system itself seems like a significant simplification for
> operations.  One less thing to go wrong when the operator doesn't
can't
> fumble finger the manually entered system ID.  Or applies the
> configuration to a system other than the DIS.
> 
> Tony