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

[Susan Hares <[e-mail]>]

Robert:

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? 

Sue 

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

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" <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

_______________________________________________
irs-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/irs-discuss