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

<stephane.litkowski@orange-ftgroup.com> Fri, 10 December 2010 09:19 UTC

Return-Path: <stephane.litkowski@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 AA5AC3A6C8A for <isis-wg@core3.amsl.com>; Fri, 10 Dec 2010 01:19:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.208
X-Spam-Level:
X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=2.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 pr6UU1rsfeOR for <isis-wg@core3.amsl.com>; Fri, 10 Dec 2010 01:19:16 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 9820D3A6C80 for <isis-wg@ietf.org>; Fri, 10 Dec 2010 01:19:16 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 8823EC027C; Fri, 10 Dec 2010 10:20:46 +0100 (CET)
Received: from puexcc31.nanterre.francetelecom.fr (unknown [10.168.74.8]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 66B6515806C; Fri, 10 Dec 2010 10:20:46 +0100 (CET)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc31.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Dec 2010 10:20:47 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Dec 2010 10:20:45 +0100
Message-ID: <8010_1291972846_4D01F0EE_8010_5949_1_4FC3556A36EE3646A09DAA60429F53350596740F@PUEXCBL0.nanterre.francetelecom.fr>
In-Reply-To: <4CFD4AC6.7090706@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Isis-wg] draft-amante-isis-reverse-metric-01
Thread-Index: AcuVhiaHyLHt1LicRhyQ626NOIAUIACwy9+A
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><309BCE56-9213-4B29-A364-B3421D952080@castlepoint.net> <4CFD4AC6.7090706@cisco.com>
From: stephane.litkowski@orange-ftgroup.com
To: raszuk@cisco.com, isis-wg@ietf.org
X-OriginalArrivalTime: 10 Dec 2010 09:20:47.0046 (UTC) FILETIME=[87520660:01CB984B]
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.12.9.164215
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: Fri, 10 Dec 2010 09:19:18 -0000

Hi all,

>From my experience point of view, for the specific framework of ISIS rerouting, there is a real need of "global configuration". Some years ago, we managed ISIS rerouting (changing metrics to high then changing back to normal to prevent traffic going on link during maintenance or link flaps) on box to box basis, people were configuring each box individually and we had some human errors on that ... To secure the operation, we developped a tool which is doing all configurations (multibox/multivendor configuration) by itself, this helped us to prevent human errors and it worked fine, but this requires extra coding (link end point detection , multi vendor configuration management ...). For our point of view, it clearly easier to manage configurations on box to box basis rather than coding complex tools (so I'm quite happy with this draft from this point of view).
If we look at network configurations more globally (not only ISIS), we are trying to work in the same way as for ISIS rerouting, we are developping tools that configures the network globally (example for BGP session, the tool is configuring both sides, for physical links or VLANS, scripts are configuring all stuffs : ports, vlans, routers, switches between ...). It's very very useful to secure operations and prevent human errors but it's very hard to us because the codes are sometimes very complex and more over we have to manage multiple vendor configurations within the same code (we must detect the vendor when connecting on the node).

Regards,

Stephane

 

-----Message d'origine-----
De : isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] De la part de Robert Raszuk
Envoyé : lundi 6 décembre 2010 21:43
À : isis-wg@ietf.org
Objet : Re: [Isis-wg] draft-amante-isis-reverse-metric-01

All,

> On a more serious note, it's important to recognize that in order to 
> mitigate human-error, we need to reduce the burden on operators to 
> "always get it right", as you seem to imply above, and certainly as 
> our executives (and customers) want us to.

Watching this thread with deep interest I must say that I am with Les here.

The problem is that this is nearly 2011 and we still do not have a good way to configure networks as an entire abstraction. We do at most - in sophisticated networks - have scripts to configure routers on a box to box basis.

Instead of working on network wide level config tool/protocol we are extending protocols to achieve the equivalent functionality. And this is not only in ISIS, we do the same in BGP, we do the same in MPLS etc ...

So while I am not seeing any harm with this draft as is I think at some point we should put serious effort to look at the network as an abstraction layer and configure such abstraction layer rather then continue the trend of extending routing protocols to deliver equivalent functionality.

That IMHO would be the best way to address the "human error" issue.

Cheers,
R.
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************