Re: [OSPF] Database Exchange Summary List Optimization

[Erblichs <[e-mail]>]

Richard Ogier,

	I am a periodic insomniac and sometimes I write code in 
	the middle of the night.

	I coded a pre-DD exchange mechanism to identify whether two
	routers are (almost) in sync and to request a partial or
	full Database exchange. This was based on some emails
	in the middle of the month.

	Yes, Acee I did re-read the earlier draft and again didn't
	like it based on not predetermining what was out-of-sync and
	thus, being able to reduce the number of header LSAs. I think IFF
	External LSAs are in sync, those headers should not be exchanged.
	In many envs, if that is the case the majority of LSA headers
	would not be exchanged. 

	I was contemplating writing a quick RFC and wanted to know whether
	you would first comment on the doc before submiting it as a
	experimental RFC later in the week.

	Mitchell Erblich
	------------------

	

Richard Ogier wrote:
> 
> 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

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