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

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.

	That seemed to be one of the agreements that came out of the session
today.

	--Tom

>
>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" <james.kempf@ericsson.com> 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>> _______________________________________________
>> irs-discuss mailing list
>> irs-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>