Re: [OSPF] Database Exchange Summary List Optimization

[Richard Ogier <[e-mail]>]

Acee Lindem wrote:

> Hi Richard,
>
> Richard Ogier wrote:
>
>> I have one concern.  What if some future extension of OSPF assumes that
>> DD packets list all LSAs as specified in RFC 2328, e.g., so that some
>> action can be taken that depends on how "out of sync" the new neighbor
>> was.  If someone implements the optimization without any indication
>> (such as a new option bit), then a future extension
>> might incorrectly conclude that the new neighbor was out of sync
>> and take the wrong action.  This could be fixed either by including
>> a new option bit, or by changing the spec of OSPF to allow the
>> optimization.  Is this a valid concern?
>
> I'm not sure that I can think of any optimization that would rely on
> the neighbor sending a full database snapshot. Especially, when you
> consider that it would need to be fully backward compatible Can
> you imagine any? 


Not really.  And you can infer the neighbor's LSDB based on the combination
of received DBD packets and LSR packets.  (If a given LSA appears in
neither type of packet, the neighbor must have the same instance.)
So I guess there is no need for the new bit.
The informational document can warn that any extension of OSPF
that uses this optimization cannot assume that the neighbor will
send a full database snapshot.

To summarize previous discussions, it looks like the (informational)
document should say that a router implementing the optimization
should do one of the following:
1. Upon receiving a DBD packet, the summary list should be updated
(as described in the document) before sending the next DBD packet.
2. If the router is master, it should list LSAs in increasing order of
(LS type, Link State ID, Advertising Router) lexicographically.
If the router is slave, it should list LSAs in decreasing order.

If option 1 is done, there is no benefit to also doing option 2.
If option 2 is done, there may still be some benefit to doing option 1
when the last DBD packet is received (with M = 0).
Option 1 may be preferable if the time to process a received full DBD packet
is much less than the time to transmit such a packet.
Otherwise, option 2 may be preferable if the database is very large
and it is desirable to reduce the time to synchronize.

However, I want to point out that option 1 does not increase the time
to synchronize, assuming the two routers already had nearly
identical databases.  Any additional delay due to not parallelizing
would be compensated for by sending fewer LSA headers.

Another variation is the following.  The DR level is Other, BDR, or DR, with
DR being the highest.  (For MANETs, we use Other, BMDR, and MDR.)
The router with the lower DR level (whether master or slave) does not
list any LSAs until the neighbor has finished listing all of its LSAs 
(indicated
by M = 0), and then lists only LSAs for which it has a newer instance.
This might be benficial since the router with higher DR level is more likely
to have newer LSAs, so the router with lower DR level will list very few
LSAs.

Richard


>
>
> Anyway, if this is a concern the document would needs to be standards
> track and I think we should use a bit in the database exchange I_M_MS
> field rather than the options (there are no free bit left in OSPFv2).
>
> Thanks,
> Acee
>
>>
>>
>> Richard
>>
>>
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf
>
>



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