Re: OSPF IGP Capabilities Draft

[Acee Lindem <[e-mail]>]

Manral, Vishwas wrote:
> 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.

Hi Vishwas,

It is true that it could not be used for determing what or what not to
flood or be included in the DB exchange. A given capability could potentially
be used to limit flooding over established adjacencies (though each
application/capability would need to be addressed separately).

>
> 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
>


--
Acee