Subject: Re: [OSPF] Database Exchange Summary List Optimization

From: Acee Lindem <[email-masked]>
Date: Fri, 14 Jul 2006 14:47:44 -0400

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?

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Erblichs <[email-masked]>
Date: Fri, 14 Jul 2006 13:21:28 -0700

Acee and Richard,

	A "ugly workaround" instead of using the DB exhange
	field could be:

	Sending a new OSPF pkt type as a REQ and if a RESP
	of that pkt type is recv, then that functionality is
	supported..

	Since, it would only be sent at the begining of the
	initial DB synch, the overhead of recving one unknown pkt
	type should be minimial. A short timeout is needed and
	if a response is not seen within the timeout, standard
	initial LSDB synch should take place.

	This is backward supported in v2 because unknown types
	are discarded. This effectively generates a private set
	of pkt types where only the aware routers will read this
	pkt type and the unaware will discard the unknown type.

	So, with that out-of-the-way.

	This same new pkt type could be a TVL type pkt, where
	each known OSPF LSA type is specified with a count, and
	a checksum-summation. If the summation matches and the
	count matches the LSA type COULD be considered synched.

	If their is any interest, I can write up a short EXP RFC
	to validate this type of functionality.

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 14 Jul 2006 17:01:43 -0400

Mitchell,

First let's see if anyone can come up with a requirement for
explicit signaling of the Richard's proposal. However, I see
absolutely on advantage to the signaling you are suggesting over
simply setting a bit in the database exchange packet I_M_MS
field.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Fri, 14 Jul 2006 15:13:27 -0700

Acee Lindem,

	The one benefit that I "sliently" thought of was the
	ability to re-send the REQ at any time AFTER LSDB
	synch has occured. A flag could be set for re-synch
	versus a new synch, which could flush the LSAs that
	originated from the REQ router.

	It is assumed that for one of many reasons, the router's
	LSDB has become un-sync'ed and is unwilling to wait
	for normal flooding or non-flooding if DNA LSAs are
	implemented. Doing a full LSDB is un-necessary.

	It also has a non-permanence to it, where a system's
	functionality support could be updated without a
	reboot / graceful restart. Isn't this an issue with
	the usage of these bits?

	Are any of these items on his wish/requirements list?

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

---

From: Hasmit Grover <[email-masked]>
Date: Sat, 15 Jul 2006 04:49:10 -0700

Hasmit Grover
[email-masked]

> 	Are any of these items on his wish/requirements list?

You could get the above resyncing  functionality  by making make sure  
that the neighbor does not reset the adjacency when it sees a DBD  
packet with the new bit set. Introducing new packet type just for  
this functionality seems to be overkill unless we can figure out any  
other use of the new signalling.

- Hasmit

---

From: Acee Lindem <[email-masked]>
Date: Mon, 17 Jul 2006 18:41:01 -0400

Hi Mitchell,

> 	originated from the REQ router.
I was hoping one of the draft authors would have said "Been there, done 
that".
See the experimental draft in the link below:

http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-05.txt

Note that flushing stale LSAs happens naturally via the existing 
database exchange
process.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Tue, 18 Jul 2006 10:08:44 -0700

Acee, et al,

	I remember the draft.

	I didn't like it because it didn't reduce the amount of exchange
	data if the two routers were almost synch. The current  method
	doesn't differ if the two routers have a different amount of
	LSDB commonality. Thus, does it really scale properly. I think I
	saw a BGP draft that can dump a large number of duplicate routes
	and they may show up as more LSAs.

	Also, it used the option bits. So, in theory a router could not
	change its capability with respect to this feature.

	Third, if a router repeatedly lost synch, their must be a
	limit on the number of resynchs per period of time. SOME
	implimentations can limit the number of LSA rexmits. If that
	happens, they will be out-of-synch, also...

	Yes, flush wasn't the right word. Lets say update as a 
	better word.

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

---

From: Richard Ogier <[email-masked]>
Date: Tue, 18 Jul 2006 10:52:38 -0700

> consider that it would need to be fully backward compatible Can

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

---

From: Erblichs <[email-masked]>
Date: Fri, 28 Jul 2006 17:26:26 -0700

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
	------------------