Re: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt

[Acee Lindem <[e-mail]>]

Hi Igor,
Igor Bryskin wrote:
> Acee,
>
>   
>>> I also think we should put the question as to whether the checking
>>> should be madatory or relaxed a bit to allow an application to check
>>> less frequently if the opaque data is stale.
>>>       
>> What benefit would this have?
>>     
> This would allow applications that don't require the opaque data to
> strictly track the SPF to discontinue using the information less
> frequently
> than the SPF. This would be useful if OSPF and the application using the
> opaque data were not tightly coupled. Here is what I put in the OSPFv3
> update draft:
>
> 3.4.4.  Future LSA Validation
>
>    It is expected that new LSAs will be defined that will not be
>    processed during the Shortest Path First (SPF) calculation as
>    described in Section 3.8.  For example, OSPFv3 LSAs corresponding to
>    information advertised in OSPFv2 using opaque LSAs [OPAQUE].  In
>    general, the new information advertised in future LSAs should not be
>    used unless the OSPFv3 router originating the LSA is reachable.
>    However, depending on the application and the data advertised, this
>    reachability validation MAY be done less frequently than every SPF
>    calculation.
>
>    To facilitate inter-area reachability validation, any OSPFv3 router
>    orginating AS scoped LSAs is considered an AS Boundary Router (ASBR).
>
> I believe that the usage of opaque LSAa and one of basic LSAs (required
> for SPF calculations) and, therefore, their validation are unrelated.
> The important thing, as you put it, is to make sure that the stale LSAs
> are not used. I mean, there is no need to provide timing recommendations
> on when and how frequent the validation of opaque LSAs should be
> performed. For example, one way to implement such validation is to make
> it event (rather, than time) driven. Specifically, the advertisements
> carried in type-11 LSAs could be marked as invalid every time when the
> corresponding type-4 LSA is removed from the LSDB.
>   
I think we are agreeing in principle. Note that while the absence of a
Router-LSA or ASBR-Summary-LSA indicates the originator is not 
reachable, the
presence doesn't guarantee reachability. The text above articulates the 
fact that an
application using OSPFv3 advertised data MAY NOT be strictly tied to the
the SPF calculation and may check LSA "freshness" at less frequent 
intervals.
However, the SPF should remain the definite source for determining 
whether an
LSA's originator is reachable.

> Cheers,
> Igor
>
>   

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf