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

Robert Raszuk <raszuk@cisco.com> Tue, 07 December 2010 22:45 UTC

Return-Path: <raszuk@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 09B053A68BA for <isis-wg@core3.amsl.com>; Tue, 7 Dec 2010 14:45:30 -0800 (PST)
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 tIhj+KXnuATF for <isis-wg@core3.amsl.com>; Tue, 7 Dec 2010 14:45:29 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 36E7A3A683D for <isis-wg@ietf.org>; Tue, 7 Dec 2010 14:45:29 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAHBI/kxAaMHG/2dsb2JhbACjSnGmboJIDgGYeIVJBIpxgxM
X-IronPort-AV: E=Sophos;i="4.59,312,1288569600"; d="scan'208";a="388702335"
Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 07 Dec 2010 22:46:54 +0000
Received: from [192.168.1.61] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oB7Mkp1O006972; Tue, 7 Dec 2010 22:46:52 GMT
Message-ID: <4CFEB95C.9020700@cisco.com>
Date: Tue, 07 Dec 2010 23:46:52 +0100
From: Robert Raszuk <raszuk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "Chen, Jay (Jay)" <jay.chen@alcatel-lucent.com>
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>
In-Reply-To: <7D0D8053DEEE4D4B9427007ADB12C2ED058E3026F8@USNAVSXCHMBSB3.ndc.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Tony Li <tony.li@tony.li>, "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
Reply-To: raszuk@cisco.com
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: Tue, 07 Dec 2010 22:45:30 -0000

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
>