Re: [irs-discuss] Suggestions for IRS Way Forward

Robert Raszuk <robert@raszuk.net> Thu, 02 August 2012 23:29 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2444011E81CE for <irs-discuss@ietfa.amsl.com>; Thu, 2 Aug 2012 16:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.014
X-Spam-Level:
X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eANkJW8Er3wH for <irs-discuss@ietfa.amsl.com>; Thu, 2 Aug 2012 16:29:58 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6557911E8169 for <irs-discuss@ietf.org>; Thu, 2 Aug 2012 16:29:58 -0700 (PDT)
Received: (qmail 7307 invoked by uid 399); 2 Aug 2012 23:29:57 -0000
Received: from unknown (HELO ?130.129.17.10?) (pbs:robert@raszuk.net@130.129.17.10) by mail1310.opentransfer.com with ESMTPM; 2 Aug 2012 23:29:57 -0000
X-Originating-IP: 130.129.17.10
Message-ID: <501B0D75.4090009@raszuk.net>
Date: Fri, 03 Aug 2012 01:29:57 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Thomas Nadeau <tnadeau@juniper.net>
References: <CC404D94.2D5D%tnadeau@juniper.net>
In-Reply-To: <CC404D94.2D5D%tnadeau@juniper.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: James Kempf <james.kempf@ericsson.com>, "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 23:29:59 -0000

Tom,

 > I agree that one of the top work items for this effort should be a
 > standardized topology function, and one that is accessible via a
 > non-routing protocol.

So if the requirement is to have topology export via non-routing 
protocol then I think we should seriously revisit or repackage the 
draft-gredler-idr-ls-distribution-01 which works for for both OSPF and 
ISIS.

However before that let's really understand the requirement why it must 
be exported via non-routing protocol .... Keep in mind that just to 
parse BGP UPDATE messages and retrieve interesting pieces out it it 
requires very little code rather then full BGP implementation.

The particular feature I like about draft-gredler-idr-ls-distribution-01 
is that it is read-only ;)

R.

>
> 	I agree that one of the top work items for this effort should be a
> standardized topology function, and one that is accessible via a
> non-routing protocol.  While not exactly "low hanging fruit", it is
> something that (to me) is a clear work item with clear goals that should
> be tackled straight away.
>
> 	--Tom
>
>
>
> On 8/2/12 3:24 PM, "James Kempf" <james.kempf@ericsson.com> wrote:
>
>> So after seeing part of Alia's talk this morning (I had to leave in the
>> middle unfortunately), I'd like to make a couple suggestions. There were
>> a lot of ideas presented in the talk, enough for an entire IETF Area. I
>> think to make tangible progress, the work needs to be focussed on a small
>> subset that would be of immediate interest and usability.
>>
>> There are a couple areas that suggest themselves, but one that would be
>> useful in work that I've been involved in is a standardized format for
>> network topology representation and a protocol for exchanging it. The
>> Onix OpenFlow controller has a network information base with a
>> specialized format for network topology, and every OpenFlow controller
>> requires this. Having a standardized way to represent it might foster a
>> common topology database package. Another application is network
>> management. Every network management system needs some kind of topology
>> representation. Finally, though I am not an expert in PCE construction,
>> it would seem to me that a PCE would need some kind of topology
>> representation in order to perform path calculations. Having a way,for
>> example, for the OpenFlow controller and the PCE to exchange topology
>> information would be really useful.  I would say to start with physical
>> topology because that is fundamental, but make the format flexible enough
>> to support
>> virtual topology representation.
>>
>> 			jak
>> _______________________________________________
>> irs-discuss mailing list
>> irs-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>