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

[James Kempf <[e-mail]>]

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
>