Re: [OSPF] Database Exchange Summary List Optimization

[Acee Lindem <[e-mail]>]

Mitchell,

First let's see if anyone can come up with a requirement for
explicit signaling of the Richard's proposal. However, I see
absolutely on advantage to the signaling you are suggesting over
simply setting a bit in the database exchange packet I_M_MS
field.

Thanks,
Acee

Erblichs wrote:
> Acee and Richard,
>
> 	A "ugly workaround" instead of using the DB exhange
> 	field could be:
>
> 	Sending a new OSPF pkt type as a REQ and if a RESP
> 	of that pkt type is recv, then that functionality is
> 	supported..
>
> 	Since, it would only be sent at the begining of the
> 	initial DB synch, the overhead of recving one unknown pkt
> 	type should be minimial. A short timeout is needed and
> 	if a response is not seen within the timeout, standard
> 	initial LSDB synch should take place.
>
> 	This is backward supported in v2 because unknown types
> 	are discarded. This effectively generates a private set
> 	of pkt types where only the aware routers will read this
> 	pkt type and the unaware will discard the unknown type.
>
> 	So, with that out-of-the-way.
>
> 	This same new pkt type could be a TVL type pkt, where
> 	each known OSPF LSA type is specified with a count, and
> 	a checksum-summation. If the summation matches and the
> 	count matches the LSA type COULD be considered synched.
>
> 	If their is any interest, I can write up a short EXP RFC
> 	to validate this type of functionality.
>
> 	Mitchell Erblich
> 	-------------------
>
> 	
>
> 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?
>>
>> 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