Re: [Isis-wg] operational problem might be solved by somehow extending current IS-IS

mike shand <mshand@cisco.com> Wed, 15 September 2010 10:02 UTC

Return-Path: <mshand@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 D8AAF3A6B89 for <isis-wg@core3.amsl.com>; Wed, 15 Sep 2010 03:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 YQXpiAb2hT5e for <isis-wg@core3.amsl.com>; Wed, 15 Sep 2010 03:02:26 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6A84A3A6B85 for <isis-wg@ietf.org>; Wed, 15 Sep 2010 03:02:26 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwGAO82kExAZnwM/2dsb2JhbACUF41acaYjnAqFQQSKLIJ+
X-IronPort-AV: E=Sophos;i="4.56,370,1280707200"; d="scan'208";a="159676354"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Sep 2010 10:02:49 +0000
Received: from [10.55.88.217] (dhcp-10-55-88-217.cisco.com [10.55.88.217]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8FA2mNl006019 for <isis-wg@ietf.org>; Wed, 15 Sep 2010 10:02:49 GMT
Message-ID: <4C9099C8.4010704@cisco.com>
Date: Wed, 15 Sep 2010 11:02:48 +0100
From: mike shand <mshand@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3
MIME-Version: 1.0
To: isis-wg@ietf.org
References: <alpine.DEB.1.10.1009141425110.13746@uplift.swm.pp.se> <C8031836-A271-46AF-9186-8BCA969065A2@tony.li> <07C45888-77B5-4A14-B5CE-726E63FEC0F5@castlepoint.net> <F1DBB6FE-472F-45E1-BF9C-7C788D662DD8@cisco.com> <C3AEB806-5A91-49D2-A8E0-B4B8222BFC74@castlepoint.net> <C5EEE2DC-34DA-4CFF-BB71-544D9838251B@tony.li>
In-Reply-To: <C5EEE2DC-34DA-4CFF-BB71-544D9838251B@tony.li>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Isis-wg] operational problem might be solved by somehow extending current IS-IS
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: Wed, 15 Sep 2010 10:02:28 -0000

  Tony,

     Changing the metric of the pseudonode might be OK, but a likely 
place where implementations might trip up is on prioritising the 
pseudonode when removing from TENT. Do they do this on the basis of it 
being zero cost, or on the basis of it being a pseudonode LSP? Currently 
either will do, of course.

     Mike


On 15/09/2010 08:22, Tony Li wrote:
> Hi Shane,
>
>> OK, switching subjects to a multi-access LAN.  Correct me if I'm wrong, but a pseudo-node LSP does not carry a metric.
>
> It carries a metric of zero.  See 7.2.3 of ISO 10589 (2002):
>
> Instead of treating a broadcast subnetwork as a fully connected topology, the broadcast subnetwork is treated as a pseudonode, with links to each attached system. Attached systems shall only report their link to the pseudonode. The designated Intermediate system, on behalf of the pseudonode, shall construct Link State PDUs reporting the links to all the systems on the broadcast subnetwork with a zero value for each supported routeing metric.
>
>
>> Regardless, I think I agree with you (?) that it's not possible to change the metric on a pseudo-node LSP.
>
> It's certainly not within spec currently, but then we ARE talking about extensions.  It would be very interesting to know how implementations reacted to this.  I suspect that most would actually process the metric in the usual fashion.
>
>
>> Furthermore, as you point out, you can't bidirectionally change a metric between just two neighbors on a multi-access LAN given that each router is only adjacent to the pseduo-node LSP, not directly to each other router.
>
> Exactly why you want to change the metric only in the pseudonode.
>
>
>> Thoughts on (c), or a better suggestion, to reduce the convergence time to more "gently" remove a node's link connected to a multi-access LAN?
>
> Are we trying to just remove one node's link?  Or are we trying to cost out the entire Ethernet?  I understood the latter.
>
> Tony
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>

-- 
For corporate legal information go to:
www.cisco.com/web/about/doing_business/legal/cri