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

<bruno.decraene@orange-ftgroup.com> Wed, 08 December 2010 08:41 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 7573F3A68C2 for <isis-wg@core3.amsl.com>; Wed, 8 Dec 2010 00:41:51 -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=[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 5-tZnIXq7xhq for <isis-wg@core3.amsl.com>; Wed, 8 Dec 2010 00:41:50 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 1AAE03A6894 for <isis-wg@ietf.org>; Wed, 8 Dec 2010 00:41:50 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0CA30798004; Wed, 8 Dec 2010 09:47:14 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0614E798001; Wed, 8 Dec 2010 09:47:14 +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:43:16 +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:43:20 +0100
Message-ID: <FE8F6A65A433A744964C65B6EDFDC24001C1585F@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <6597659E-DB95-495D-8232-2DCF8C4F7163@castlepoint.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Isis-wg] draft-amante-isis-reverse-metric-01
Thread-Index: AcuWZfjxCNEzL+4cTDiP5m+9+zDPCwATMDRw
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> <975530EB-90F0-4FFA-AA5A-E1FBA7160439@tony.li><4CFD4E2F.6040601@cisco.com><7D0D8053DEEE4D4B9427007ADB12C2ED058E3026F8@USNAVSXCHMBSB3.ndc.alcatel-lucent.com><4CFEB95C.9020700@cisco.com> <6597659E-DB95-495D-8232-2DCF8C4F7163@castlepoint.net>
From: bruno.decraene@orange-ftgroup.com
To: shane@castlepoint.net
X-OriginalArrivalTime: 08 Dec 2010 08:43:16.0614 (UTC) FILETIME=[F521DA60:01CB96B3]
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:41:51 -0000

Shane,

> 
> Robert, Bruno, (Jay),
> 
> It is an explicit /non-goal/, even outside the context of this draft,
to
> port an NMS system and/or configuration generation system *into*
IS-IS.
> Call me old-school, but a routing protocol, (particularly an IGP),
should
> only distribute topology/reachability information, as fast as [is,
safely]
> possible.  Asking that routing protocol to also push around counters
(snmp
> over IS-IS <barf>), general-purpose configuration information (netconf
> over IS-IS <barf>), etc. is contrary to that goal for all the reasons
that
> you're already familiar with.  :-)

May be I was not clear in my previous email but your above text does not
reflect what I meant.

1) From a protocol standpoint, by

> From: bruno.decraene@orange-ftgroup.com
> 
> 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.

I meant _regular_ management protocols. E.g SNMP over UDP/IP or netconf
over TCP/IP. Nothing related to IS-IS, especially _not_ "snmp over IS-IS
<barf>"


2) From a general standpoint, I did not mean to port NMS into IS-IS,
quite the contrary in fact.

Bruno

> To be more clear, the scope of this draft is to make operation of an
IS-IS
> network dramatically less error-prone by simplifying the handling of
_a_
> (notice the explicit use of the singular) very well-known,
widely-used,
> routine maintenance procedure that occurs on networks day-in and
day-out,
> the world over, _specifically_: p2p link /and/ multi-access LAN
isolation.
> 
> Thanks,
> 
> -shane
> 
> 
> On Dec 7, 2010, at 15:46 MST, Robert Raszuk wrote:
> > Hi Jay,
> >
> > Just one clarification ...
> >
> > What I and also Bruno pointed out was a bit more restrictive that
your
> interpretation :)
> >
> > While each node would be an equal class citizen in such ability to
> configure the network or to set a parameter of a p2p or p2mp link it
does
> not mean that one would essentially need to enable such ability on
each
> node.
> >
> > Clearly also it would not be available to anyone. Only to the same
> access level as today allowing for configuration.
> >
> > As to the topic of what protocol would fit such role I do agree with
> your comment that we would probably need some form of hybrid. The
reliable
> domain wide flooding should be combined with incremental updates
ability.
> >
> > Volume wise I am not sure we are to have "huge volumes". Clearly
what
> differs this type of fundamentally different approach to NMS that it
is
> not targetted to be a carrier for SNMP pooling stats or netflow
records.
> >
> > Many thx,
> > R.
> >
> >> wide config making each router to be an NMS station. Call it
C-ISIS.
> >> Example: instead of configuring links on the adjacent nodes
configure
> >> link parameter anywhere, instead of configuring node at a node ..
> >> configure it anywhere.
> >>
> >> Very interesting. Configure anywhere by anyone (maybe any computer)
> >> will be every powerful and very scaring too (security). A graph of
> >> network and transport of configure information will be needed. If
> >> protocol is proposed to do the job, should be a single protocol
best
> >> fit? ISIS does know the topology of the network, on another hand
BGP
> >> is better to transmit huge data and does incremental updates
> >> reliablely. A combination of functions from multiple protocol seems
> >> better than extending a single protocol.
> >>
> >> Jay
> >>
> >>
> >> Many thx, R.
> >>
> >> PS.
> >>
> >> /* After all we have many uses for ISIS today ... TRILL included :)
> >> */
> >>
> >>
> >>> Robert,
> >>>
> >>>> 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, you're suggesting that we stop work on improving protocols
> >>> until the NMS folks get their act together.
> >>>
> >>> This doesn't seem like a practical suggestion.
> >>>
> >>> Regards, Tony
> >>>
> >>>
> >>
> >> _______________________________________________ Isis-wg mailing
list
> >> Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
> >>
> >
> > _______________________________________________
> > Isis-wg mailing list
> > Isis-wg@ietf.org
> > https://www.ietf.org/mailman/listinfo/isis-wg
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg