IETF Logo Mail Archive

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

Christopher Liljenstolpe <cdl@asgaard.org> Wed, 08 December 2010 01:22 UTC

Return-Path: <cdl@asgaard.org>
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 39A633A68D7 for <isis-wg@core3.amsl.com>; Tue, 7 Dec 2010 17:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 KReGtA5u+J-m for <isis-wg@core3.amsl.com>; Tue, 7 Dec 2010 17:22:37 -0800 (PST)
Received: from asgaard.org (ratatosk.asgaard.org [204.29.150.73]) by core3.amsl.com (Postfix) with ESMTP id 840413A68DC for <isis-wg@ietf.org>; Tue, 7 Dec 2010 17:22:37 -0800 (PST)
Received: from [10.245.3.222] (unknown [110.150.218.86]) by asgaard.org (Postfix) with ESMTP id A51649F158E; Wed, 8 Dec 2010 01:24:01 +0000 (UTC)
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>
In-Reply-To: <FE8F6A65A433A744964C65B6EDFDC24001BDAE10@ftrdmel0.rd.francetelecom.fr>
Mime-Version: 1.0 (iPad Mail 8C148)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Message-Id: <3E27AEBF-4F8A-40D1-8D3E-C6F937D1CA1F@asgaard.org>
X-Mailer: iPad Mail (8C148)
From: Christopher Liljenstolpe <cdl@asgaard.org>
Date: Wed, 08 Dec 2010 12:23:55 +1100
To: "<bruno.decraene@orange-ftgroup.com>" <bruno.decraene@orange-ftgroup.com>
X-Mailman-Approved-At: Thu, 09 Dec 2010 05:27:06 -0800
Cc: "<isis-wg@ietf.org>" <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 01:22:41 -0000

Greetings,

Sent from a slightly less silly keyboard.


On 7 Dec 2010, at 19:43, <bruno.decraene@orange-ftgroup.com> wrote:

> [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?

> Regards,
> Bruno
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>

v2.23.0 | Report a Bug | By Email