Re: [OSPF] Database Exchange Summary List Optimization

[Acee Lindem <[e-mail]>]

We had a  majority of the attendees in favor of making this a WG
document in Montreal. Is there anyone not in favor of adopting it as
an informational WG document?

I know there are those who feel we shouldn't publish any document
that is fully compatible. However, in this case, IMHO, it is worthwhile for
the WG to do so since:

    1. WG discussion and review will verify with a high probability
         that this change is, in fact, fully backward compatible.
    2. We'd be accepting a document that most people agree is a
         good thing to do - there is less disagreement on the details
         then some other proposals.
    3. The relatively simple optimization can result in a significant
        decrease in DB exchange overhead. In fact, I predict option A
        will some day be in most implementations.

Thanks,
Acee
      

Richard Ogier wrote:
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf
>

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