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

Susan Hares <> Fri, 10 August 2012 19:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C416711E809A for <>; Fri, 10 Aug 2012 12:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 05lMSmvmxdYY for <>; Fri, 10 Aug 2012 12:19:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 05EAC11E8099 for <>; Fri, 10 Aug 2012 12:19:51 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.2.3-GA FastPath) with ESMTP id AIS74784; Fri, 10 Aug 2012 11:19:51 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Aug 2012 12:17:36 -0700
Received: from ([]) by ([]) with mapi id 14.01.0323.003; Fri, 10 Aug 2012 12:17:32 -0700
From: Susan Hares <>
To: "" <>, Thomas Nadeau <>
Thread-Topic: [irs-discuss] Suggestions for IRS Way Forward
Thread-Index: Ac1w/aRFxquJYy0LSJCFfpb4MILlegAO51CAAAIJPoABepTsoA==
Date: Fri, 10 Aug 2012 19:17:32 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: James Kempf <>, "" <>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Aug 2012 19:19:52 -0000


Here's the questions I have to the authors of this draft: 

1. How does this draft prevent sending this non-routing information to the whole BGP peers?

    The draft says private peering.  The question is regarding the private peer - is do the implementations 
    Have the knobs to aid the detection and enforcement of this private peering? 

    I believe you have seen the questions by operators (e.g., Rob).

2. How does this draft impact the ROA work? Is it orthogonal?  Will the ROA work be turned off
   For the draft-gredler-idr-ls-distribution-01? 

3. Is this for IBGP only?  Or is it for EBGP in AS Confederations? 
   How does the RR infrastructure get protected? 


-----Original Message-----
From: [] On Behalf Of Robert Raszuk
Sent: Thursday, August 02, 2012 4:30 PM
To: Thomas Nadeau
Cc: James Kempf;
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward


 > 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 

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 ;)


> 	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" <> 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 mailing list

irs-discuss mailing list