Re: [OSPF] Database Exchange Summary List Optimization

Hi Richard,

On Thu, 31 Aug 2006, Richard Ogier wrote:

> It seems clear that Option 1 should remain in the document

Yes.

> (1) With Option 2, the DR always lists all LSAs in its database, 
> while the DR Other lists only LSAs for which it has a more recent 
> instance than the DR. Therefore, even if the two routers are 
> completely out of sync, and assuming the DR has more recent 
> instances (which is more likely), the DR Other will not list any 
> LSAs. In this case, if Option 1 were used, the DR Other would list 
> roughly half of its LSAs on average (i.e., the LSAs that are not 
> first listed by the DR), and the DR would still list all of its 
> LSAs (assuming they are more recent), so Option 2 has an advantage 
> over Option 1 in this case.

> (2) The second advantage of Option 2 is that the DR Other will
> list far fewer LSAs (and thus transmit fewer bits) than the DR
> on average.  This may be useful in a MANET, since the DR Other
> may be less powerful than the DR, and thus have a lower router
> priority.  Therefore, the less powerful router transmits fewer
> bits, which makes sense.

> For the above two reasons, I think Option 2 is useful and should 
> remain in the document.

It may need refinement in language though. E.g. Acee's point about DD 
being a strictly master-driven process and sequence numbers..

> The main question I have is whether Option 3 is useful enough
> to remain in the document.

No.

There are two possibilities for 3/C:

a) It occurs naturally as a result of the index the implementation
    uses for the summary list

b) The implementation must go through contortions to try meet this
    requirement

I would suggest perhaps instead only mentioning the benefits of 
implementations ordering their index in that manner, and encourage 
implementations to try do so if possible.

Also, note that even /partial/ ordering would have benefits. e.g. 
just ordering by (type) or (type,ID).

<option 2/B discussion>:

> Acee told me he does not see a great advantage to sending the
> next DD packet prior to processing the received one,
> and that this may be a protocol violation since the DD packet
> sent in reply effectively acks the received one.

Yep.

> So one question is whether it is possible to effectively
> ack a received DD packet without first processing the
> list of LSA headers in the packet, or at least reading
> the LSA headers to make sure they are valid.

Yes, just ACK it. As long as slave keeps ACKing or master keeps 
polling, with More set, Exchange should continue (modulo 
implementation bugs :), and 2328 isn't quite as clear on this as it 
perhaps it could be due to redundancy in description of Exchange, so 
there is some appreciable real-world risk here.).

I think the text for 2/B perhaps(?) would be better as, if I 
understood the intention correctly:

  "The router with the lower DR level should continue to acknowledge
   DD packets or poll for further DD packets, in accordance with which
   role of Slave or Master it is in, but should do so with empty DD
   packets with the More bit set.

   LSA headers received may be set aside, their processing deferred
   until a DD packet is received from the neighbour with the More
   bit clear.

   After which the implementation should proceed normally with
   Exchange, describing whatever LSAs it has left on its summary list
   to the neighbour."

That ought to get you the 'one side describes first, then the other' 
behaviour, and is in spec (Exchange does not end until both sides 
have sent DD with More clear, according to 2328), I think.

Another option, more disruptive, is to observe that the language 
could be made more simple if it could be guaranteed that Master/Slave 
always corresponded with the DR level (reduces a combination). It's 
unfortunate it's a tri-state, otherwise it could be achieved with 
just one extra DD-flag, but with 2 flags one could arrange that, 
between neighbours implementing the draft, the roles would be 
aligned. Wouldn't be as transparent though, compatibility wise.

FWIW: Quagga 'ospfd' has an implementation of option A, in CVS HEAD.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
There are few people more often in the wrong than those who cannot endure
to be thought so.

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