Re: [OSPF] Database Exchange Summary List Optimization

[Erblichs <[e-mail]>]

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

	


Acee Lindem wrote:
> 
> Hi Mitchell,
> 
> Erblichs wrote:
> > 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.
> >
> 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
> 
> >       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
> >       -------------------
> >
> >
> >
> >
> > Acee Lindem wrote:
> >
> >> 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
> >>
> >> Erblichs wrote:
> >>
> >>> 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
> >>>       -------------------
> >>>
> >>>
> >>>
> >>> 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?
> >>>>
> >>>> 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