Re: [OSPF] Database Exchange Summary List Optimization

[Richard Ogier <[e-mail]>]

Hello Mitchell,

Thanks for your comments.  I agree with Acee's response,
and I have a few more comments below.

Erblichs wrote:

>Group,
>
>	I did not hear Acee's presentation, but have read the
>	two page draft.
>
>	You mention
>	"This optimization reduces Database Description
>         overhead by about 50% in large networks." I feel
>	only in the last scenario, this statement may be
>	true. However, In the simple, BMA
>
>        environment, the DR will contain most of the LSAs
>	(scenario 3), I doubt that any reduction would be
>	significant.
>
>
>
>	I am less aware of P2P,etc type environments, where this
>	might be more signficant, thus I suggest a fine tuning
>	to this idea below.
>
>	Upon my first quick read, 4 scenarios came to mind:
>	1) a minimal number of LSAs that need to be exchanged
>	   on both sides.
>	2) a large number of LSAs that need to be exchanged
>	   on both sides and they are from two past DRs,
>	   thus no LSA header will match...
>	3) a new adj where the DR has already formed adjs
>	   and a new router where only a few of its LSA
>	   need to be exchanged.
>	4) two routers have basicly the same LSA list.
>

The optimization is mostly indended for the last scenario,
which is often the case in MANETs.  The following sentence from
Section 1 of my draft implies this:
  "The optimization reduces
   Database Description overhead by about 50% in large networks, since
   it reduces the total number of LSA headers exchanged by about one-
   half when the two routers are already nearly synchronized."

>
>
>	IF I read the draft correctly, one or both routers are
>	creating a artifical delay before some LSAs are sent.
>	One router might wait until it thinks it has recieved
>	all of the other router's LSA headers.
>

There is no additional delay.  It is important that the received
DD packet be processed completely (including updating the summary list
as specified in my draft) before the next DD packet is sent in response,
and I will clarify this in the draft. As a result, the next sent
DD packet will not list any LSAs that were listed in the received
DD packet (with the same or newer instance).

>
>
>	This delay introduces a longer period of time before
>	the OSPF routers could be synchronized. This is
>	expecially true if the waiting router is holds a number
>	of new LSAs. Thus, you are optimizing for the last
>	scenario.
>
>	If (my theorectical two minute thought suggestion)
>	implemented ordered LSAs, and both routers could
>	agree on a order... stay with me..
>
>	   Wouldn't it make more sense that the master say send
>	increasing LSAs ids out and the slave send decreasing
>	LSAs out?
>

As Acee mentioned, the ordering does not matter, as long as the received
DD packet is processed before the next DD packet is sent in response.

>
>
>	One could then theorectly compare LSAs and implement what
>	you suggest without delay. In #1, Since the number of LSAs
>	is small, the LSAs will still be exchanged. But where the
>	number of LSAs is LARGE and almost identical between the 
>	two routers, then half the number of headers would be sent.
>

Right. That was the main intention. This has been shown in simulations
of OSPF-MDR (for MANETs) using GTNetS.

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?

Richard

>
>
>	Thus, IMO, a new option should be specified that says that
>	the two will exchange in the initial database sync, in reverse
>	order. Again, this will help a DR/BDR full adj formation, only 
>	if that is done last.
>

>
>
>	Mitchell Erblich
>	-------------------
>
>
>Acee Lindem wrote:
>
>>Hi Richard,
>>Richard Ogier wrote:
>>
>>>I listened to Acee's presentation of my draft
>>>http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt
>>>
>>>Acee mentioned that it might help to list the LSAs in
>>>lexicographical order, to achieve the maximum savings
>>>in overhead.  One person commented that it may not be
>>>reasonable to require this.
>>>
>>>I want to point out that one can still achieve the 50% reduction
>>>in the number of LSA headers exchanged even if LSAs are not
>>>listed in lexicographical order, as long as the received DD packet
>>>is processed completely (including updating the summary list
>>>as specified in the draft) before the next DD packet is sent.
>>>In this case, I don't think the order in which LSAs are listed
>>>matters.
>>>
>>>Comments?
>>>
>>I agree. I probably shouldn't have mentioned lexigraphically ordering
>>at all since it was with respect to how simple and low overhead this
>>optimization is when starting  with an implementation
>>following RFC 2328.
>>
>>Given this fact,  I'd ask the question again as to whether anyone
>>is opposed to publishing this as an informational WG document?
>>
>>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