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

Jan,

I think that the topology data-model for IRS would not be confined to
what can be learned from a single router.  It could be partially
populated from a single router.  An application can talk to multiple
routers to learn the topology; in the same way an application could
need to install static routes at multiple routers.

A topology-server could talk to as many devices (routers, databases,
etc) as necessary to completely fill out the topology data-model.

An area that would be quite fruitful to discuss is the multiple
abstraction layers as well as, perhaps, some of the physical layers
and attributes that would be good to include.

I'd really like to get some productive brainstorming done on use-cases
related to the topology data-model.

I think we might be able to just have a single use-cases and
requirements draft in this area - but we'll have to see how large that
gets.

I know that many of us are quite eager to get to the topology
data-model and how it would be populated (and BGP-LS is probably a
good way for some of the information), but getting on the same page as
far as use-cases and requirements (while quietly writing data-models
in the background for sanity-checking) seems like a good first step to
me.

Alia

On Fri, Aug 3, 2012 at 1:33 AM, Jan Medved (jmedved) <jmedved@cisco.com> wrote:
> Tom,
>
> On 8/2/12 4:42 PM, "Thomas Nadeau" <tnadeau@juniper.net> wrote:
>
>>
>>
>>On 8/2/12 4:29 PM, "Robert Raszuk" <robert@raszuk.net> wrote:
>>
>>>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.
>>
>>       Cool.
>>
>>
>>>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.
>
> Agreed.
>
>>
>>       That seemed to be one of the agreements that came out of the session
>>today.
>
> Can you give more background?
>
> I don't think it's as straightforward. BGP-LS implements a network-wide
> model (data schema), while the scope of IRS is a single node (IMO as it
> should be). A node's local IGP and BGP databases do not provide the view
> of the entire network topology. To get the whole topology, multiple
> routers need to be queried, and the topology needs to be 'stitched'
> together. This can either be done in an external node (an ALTO Server, for
> example), or in a router.
>
> If the 'stitching' is done in an external server, would it mean that the
> scope of IRS is extended to entities other than routers?
>
> If the 'stitching' is done at a router, then the router would have to
> collect the topology data from other routers - using BGP-LS, for example
> ;-) The topology export would then basically have to provide access to the
> BGP-LS database through some adaptation function. I wonder what's the gain
> in this case...
>
>>
>>       --Tom
>>
>
> Thanks,
> Jan
>
>>
>>>
>
> _______________________________________________
> irs-discuss mailing list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/irs-discuss