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

<bruno.decraene@orange-ftgroup.com> Wed, 08 December 2010 08:59 UTC

Return-Path: <bruno.decraene@orange-ftgroup.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 F10553A6907 for <isis-wg@core3.amsl.com>; Wed, 8 Dec 2010 00:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
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 RatR-6PeV9mB for <isis-wg@core3.amsl.com>; Wed, 8 Dec 2010 00:59:40 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 18EF63A68B3 for <isis-wg@ietf.org>; Wed, 8 Dec 2010 00:59:40 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6F05A8B8010; Wed, 8 Dec 2010 09:57:07 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 133868B8011; Wed, 8 Dec 2010 09:54:03 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Dec 2010 09:53:04 +0100
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: Wed, 08 Dec 2010 09:53:09 +0100
Message-ID: <FE8F6A65A433A744964C65B6EDFDC24001C1588C@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <3E27AEBF-4F8A-40D1-8D3E-C6F937D1CA1F@asgaard.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Isis-wg] draft-amante-isis-reverse-metric-01
Thread-Index: AcuWdpqilT7/OHueR1mrQluO6NlnZAAPXBzw
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> <alpine.DEB.1.10.1012070718430.27193@uplift.swm.pp.se> <FE8F6A65A433A744964C65B6EDFDC24001BDAE10@ftrdmel0.rd.francetelecom.fr> <3E27AEBF-4F8A-40D1-8D3E-C6F937D1CA1F@asgaard.org>
From: bruno.decraene@orange-ftgroup.com
To: cdl@asgaard.org
X-OriginalArrivalTime: 08 Dec 2010 08:53:04.0547 (UTC) FILETIME=[53914F30:01CB96B5]
Cc: 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: Wed, 08 Dec 2010 08:59:41 -0000

> > [Warning: thinking out loud...]
> >
> > a) I understand the need to cost out a link with a single CLI on a
> > single router.
> > b) I hear that some would prefer management action be done with
> > management protocols rather than routing protocols extensions.
> >
> > So what about doing (a) with management protocols? i.e. a router A
> > providing a single CLI and triggering the remote action on router B
> > using management protocols.
> > That would also serve as a test to see by ourselves if this is
> > convenient or if those management protocols need enhancement. It
could
> > also be reused as an example for NMS to do it by themselves next
(next?)
> > time.
> >
> 
> Nice in theory.  What mgmt protocol will
> A) figure out the peer router
> B) figure out the peer link on said peer router
> C) temporarily cost out that link
> D) in a multiple-vendor network?

So if it's difficult / impossible, may be NMS or SP network management
systems are not the one to blame, actually. May be current IETF
management tools / framework need to be extended.

Regards,
Bruno