Re: [OSPF] Database Exchange Summary List Optimization

I have submitted the following updated draft:
http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-01.txt

The update incorporates comments of others and some ideas I presented
in my post on 7/18/2006.  In particular, it describes three options
that differ in whether the LSAs must be listed in lexicographical order
and whether a router must fully process a received DD packet before
sending its next DD packet.  To summarize:

In Option A, the router is required to fully process a received DD
packet before sending the next DD packet in reply.
(LSAs are not listed in lexicographical order.)

In Option B, the router with the larger DR level performs database
exchange as in RFC 2328 without change.  The router with the smaller
DR level sends only empty DD packets (with no LSA headers) until it
has received the entire summary list from its neighbor (indicated
by M = 0), and then lists only LSAs that are more recent than those
received.  I forgot to mention in the draft that Option B applies
only to broadcast (or MANET) interfaces.

In Option C, the master lists LSAs in lexicographical order
and the slave lists LSAs in reverse lexicographical order,
as suggested by Mitchell Erblich.

Regarding recent comments by Mitchell, I am not yet convinced that
there is any benefit to detecting whether a neighbor is nearly in sync
and using the optimization (with one of the three options) only if
the neighbor is nearly in sync, versus simply employing the
optimization.  For example, in MANETs, it appears best to simply
employ the optimization with Option A.
Maybe you can provide a concrete, realistic example.

Even if it does help to detect whether a neighbor is nearly in sync,
I am not sure that the (informational) document I am working on
needs to specify such a detection mechanism.  Such a mechanism
could be specified in a separate document.  Instead, the document I
am working on can just state that such a mechanism can be employed
if desired.  If two routers are performing database exchange, the
protocol does not fail if only one of the routers decides to use
the optimization, or if one router decides to use Option A while the
other decides to use Option B or C.

Of course, this optimization was motivated because we wanted
to reduce overhead in MANETs, and I would prefer to keep
the document as simple as possible.

Richard

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf