Re: OSPF IGP Capabilities Draft

[Acee Lindem <[e-mail]>]

Abhay Roy wrote:
> Acee,

Hi Abhay,

>
> One of the questions raised was, why do we need to advertise these
> capabilities? I am glad to see that, there is at least one useful
> application (as in PCSD).

Yes and I think there will be others in the future.

>
> I still have those reservations about the usefulness of many other
> 'capabilities' this document describes. IMHO, if the receivers of
> these capabilities are just going to display it in a 'show'
> command, we should NOT specify them in this document.

Since these are existing mechanisms we really can't make the
receivers have any dependence on them. However, I'm not sure
that is a reason not to allow the bits to be advertised with
other router capabilities which are dependent on the
IGP capabilities mechanism.

>
> Regards,
> -Roy-
>
> On 01/30/03-0500 at 9:28pm, Acee Lindem writes:
>
>
>>As many of you recall, we've discussed this draft at both
>>the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama
>>but apparently there were some present who voiced reservations
>>with the draft. In Atlanta, there wasn't a lot of discussion (other
>>than strong support from the authors ;^). We agreed to discuss this
>>draft further on the OSPF list.
>>
>>Are there still people who have reservations with the draft?
>>
>>http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt
>>
>>[Speaking as a WG member]
>>
>>I think the draft is a natural mechanism for advertising new OSPF
>>capabilities now that the LSA option bits have been exhausted.
>>We've already extended OSPF to support traffic engineering (TE)
>>information and this mechanism is slated to be used for propagating
>>an OSPF router's ability to act as an MPLS TE path computation
>>server (PCS).
>>
>>Thanks,
>>--
>>Acee
>>
>
>


--
Acee