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

[Susan Hares <[e-mail]>]

Jan:

The real question about this data is the operational questions and aids? For example, 

a) Did the implementations allow ISIS topology to be easily put in this new BGP draft,
b) Do the implementations have filters to prevent this new BGP AFI/SAFI being put in v4/v6 AFI/SAFI BGPs,
c) Is it wise to run both in the same process? Or should it be recommended to have two processes? 
d) Have implementers or Service providers tried a test case about putting the ISIS topology into the base protocol. 
f) What type of special failure cases can the RR have? 

Summary... It's possible, but do implementations have knobs (in any form) to prevent disaster.  

Sue 


-----Original Message-----
From: Jan Medved (jmedved) [mailto:[e-mail]] 
Sent: Thursday, August 02, 2012 9:11 PM
To: Susan Hares; James Kempf; [e-mail]
Cc: [e-mail]
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Sue,

On 8/2/12 6:15 PM, "Susan Hares" <[e-mail]> wrote:

>James:
>
>BGP and ISIS may have overkill - or it may be just right.  Realize - this
>information does not come for free.

Agreed. 

It costs to extract the topology information from the router, and it costs
to process it a the client. A routing protocol is a good low cost
interface to get topology data out of a router, since routing is one of
the things that routers are optimized for.

Now, if a client does not want to listen to BGP Updates (which is not that
difficult to implement, as Robert pointed out), we can have an
intermediary, such an ALTO Server, which will receive routing protocol
updates and provide the topology to clients in an easier-to-digest format.

>
>You are running BGP sessions across the network passing this information.
>All of the routers must be configured and instrumented separately from
>the regular BGP. ISIS uploaded into these BGP sessions and distributed.

Not necessarily. In a single-area IGP, a single BGP-LS speaker listening
to IGP updates can retrieve the IGP topology for the whole network. Other
BGP Speakers in the network do not need to be BGP-LS enabled at all.

If we want to retrieve a complete topology of a multi-area IGP network,
there must be an IGP listener in each IGP area. If a client wants to use
BGP-LS to retrieve the IGP topology from the network, it can set up a
BGP-LS session to each of the IGP listeners (in each area). Alternatively,
we can use a Route Reflector to collect the topology data from all BGP-LS
Speakers; then, the client only needs to establish a single session to the
Route Reflector. Also, the Route Reflector can service multiple clients.
Note that in this case there too is only a small set of routers than need
to be BGP-LS enabled.

Basically, we leverage existing BGP mechanisms to collect the topology
data from the entire network. We can leverage an existing Route Reflector,
or we can dedicate a Route Reflector just for BGP-LS. Talking to multiple
operators, they prefer the latter option.

>
>Please ask the authors about the details of their implementations.

Sure, if more details are required, we'll be glad to discuss :-)

>
>Sue 
>
Thanks,
Jan

>
>-----Original Message-----
>From: James Kempf [mailto:[e-mail]]
>Sent: Thursday, August 02, 2012 4:53 PM
>To: Susan Hares; [e-mail]
>Cc: [e-mail]
>Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
>
>I'll have to take a look at draft-grendler, I am not familiar with it.
>
>The particular use cases I'm interested in are NMS and OpenFlow
>controller type applications where some centralized entity wants
>information on the topology for managing the elements in a way that
>allows policies to be expressed over the network as a whole and
>translated into specific element management polices by the controller/NMS
>system. The topology data base must be populated somehow, obviously, but
>I assume that would be part of the work (perhaps draft-grendler describes
>this). The physical topology won't be exported outside an operator's
>domain since managing the physical infrastructure is under the purview of
>the operator. If the topology database supports expressing virtual
>topologies (which I believe it should) the operator could expose virtual
>topologies to the customers of the virtual networks, and allow them the
>ability to manage their virtual slices.
>
>Make sense?
>
>			jak  
>
>> -----Original Message-----
>> From: Susan Hares [mailto:[e-mail]]
>> Sent: Thursday, August 02, 2012 4:30 PM
>> To: [e-mail]; James Kempf
>> Cc: [e-mail]
>> Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
>> 
>> James:
>> 
>> This is the full detailed routes.  However, will every ISP
>> share it's ISIS topology.
>> 
>> Sue 
>> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Robert Raszuk
>> Sent: Thursday, August 02, 2012 4:21 PM
>> To: James Kempf
>> Cc: [e-mail]
>> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
>> 
>> Hi James,
>> 
>> On the topic of topology export it is my understanding that
>> we do already have a solution which in fact even authors of
>> IRS framework support and are putting under their umbrella.
>> 
>> That is: 
>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01
>> 
>> The draft as standards track document defines the topology
>> export standard in form of link and node NLRIs with bunch of TLVs.
>> 
>> So the key aspect would be to see what is missing and if
>> something is missing in the space of topology export to
>> evaluate if this solution by principle can be extended to
>> accommodate it.
>> 
>> Best,
>> R.
>> 
>> 
>> > 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