Re: [OSPF] Database Exchange Summary List Optimization

[Hasmit Grover <[e-mail]>]

Hasmit Grover
[e-mail]



On Jul 14, 2006, at 3:13 PM, Erblichs wrote:

> Acee Lindem,
>
> 	The one benefit that I "sliently" thought of was the
> 	ability to re-send the REQ at any time AFTER LSDB
> 	synch has occured. A flag could be set for re-synch
> 	versus a new synch, which could flush the LSAs that
> 	originated from the REQ router.
>
> 	It is assumed that for one of many reasons, the router's
> 	LSDB has become un-sync'ed and is unwilling to wait
> 	for normal flooding or non-flooding if DNA LSAs are
> 	implemented. Doing a full LSDB is un-necessary.
>
> 	It also has a non-permanence to it, where a system's
> 	functionality support could be updated without a
> 	reboot / graceful restart. Isn't this an issue with
> 	the usage of these bits?
>
> 	Are any of these items on his wish/requirements list?
>

You could get the above resyncing  functionality  by making make sure  
that the neighbor does not reset the adjacency when it sees a DBD  
packet with the new bit set. Introducing new packet type just for  
this functionality seems to be overkill unless we can figure out any  
other use of the new signalling.

- Hasmit

> 	Mitchell Erblich
> 	-------------------
>
> 	
> 	
>
> Acee Lindem wrote:
>>
>> 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

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