Re: OSPF IGP Capabilities Draft

["Manral, Vishwas" <[e-mail]>]

Hi Acee,

The only reservation that I have with the mechanism for OSPF is that it
cannot be used as a means to define what LSA's are exchanged/whether
adjacencies are to be formed etc., because the LSA's are only exchanged
after the decisions have already been made. So capabilities similar to the
current Opaque capability/NSSA/Stub capability cannot be exchanged using the
LSA's.

However if we allow the LSA to be exchanged even before the decision to form
adjacencies, we can get over the issue(we would require a change in
protocol). It could also help in a case similar to the unplanned hitless
restart case, where LSA's are exchanged even before Hello's are exchanged.

I however agree that this method is better than allowing a whole lot of
LSA's(like the Grace LSA for unplanned restart being used now), to be
flooded before the neighbor state, that the protocol allows it.

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:[e-mail]]
Sent: Sunday, February 02, 2003 3:56 AM
To: [e-mail]
Subject: Re: OSPF IGP Capabilities Draft


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