Re: About OSPF route flapping

[Erblichs <[e-mail]>]

Joel Halpern, et al,

	First, my suggestion, past experimental implimentations
	are local to the link. Link costs are two directional
	determined by the two routers on both sides of the link.
	Since link costs are additive (directional per hop)
	only those routes that potentially pass thru those links 
	will incure those costs.

	Secondary issues is the freq of changing costs that will
	generate new SPF calcs. The below suggested link cost scenario
	SHOULD minimze repeated SPF calcs.

	Second, I know of no other ideas that in the next below
	example will not decrease the up time of the link if
	link cost is not adjusted other than to do NOTHING.

	Ex: Router A's link w.x.y.z comes up and stays up for
	about 4 minutes at a time. After that 4 minute time
	period, the link goes down for 1 minute. Their are
	routes that are only accessible via this router's
	interface. It then repeats with another 4 min up time.

	Now in this example we will know that the link is
	down after the dead router timer expires (30 secs)
	for simplicity. And immediately after the link comes
	up it will send a hello without any neighbors listed.

	So, it is down for 30 secs at the end of our up time
	before we are sure that it is down.

	We could also use router LSAs used by the originator
	after the fact on the flapping interface when it is
	back up. Or...

	What do we do?

	0) Do nothing..

	A) If we follow the BGP like implimentation and allow
	   the non origination router or the origination router
	   to delay link up status notification each time, then
	   the routes that are accessible only via this "unstable"
	   link will have less up time when it is available.
	   It is that simple. Any threshold will increase the
	   link's unavailability when too agressive and will lead
	   to repeated SPF calcs when not agressive enough.Any
	   method of route-WITH-HOLDING MUST be used by all
	   routers unless it was done at the originator.

	B) IT IS Preferable having the originator increase the cost 
	   of the link to allow routes that can transit other paths, 
	   take those other routes and those that can't be forced 
	   to rexmit or be dropped when the link is down.

	   This allows that during that 30 sec period that we aren't
	   sure that the router's link is down to use alternative routes
	   when available.

	   This also allow those routes that are only accessible
	   thru this link to have 4 minutes of up connectivity
	   every 5 minute period.

	   Since the originating router can't update the link
	   cost on this link when it is down, it is prefered that
	   some history is kept and that the next time the link
	   comes up a cost increase is implimented. My assumption
	   is that a multicative increase is best while we are
	   in periods of "instability" and slowly decrease it
	   as we become more stable over time.

	   1. if the other side of the link is aware of the
	      unstability, it can boost its link cost to allow
	      other route paths to be used for some pkts 
	      and not pushed into the router's link for the 
	      30secs that it takes to determine that the link is 
	      down.

	  2) This (boost link cost) can also be done on the router's 
	     other interfaces at the time the interface is determined
	     down. We can do this because a percentage of pkt will
	     enter one interface and be directed out towards the
	     dead interface.

	  Since only the orignator's link and the nbr's link
	  make the link cost change, this change SHOULD be completely
	  transparent and only infrequent additional LSAs are
	  re-originated with different link costs.

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

	

"Joel M. Halpern" wrote:
> 
> Actually,
> a) this is local policy and does not need standardization
> b) this is not obviously the "right" thing to do.  If the link is really
> flapping badly, the local node might well decide to advertise it as down,
> on the grounds that pretending it is useful is actually misleading.  I
> could imagine an implementation offering all sorts of knobs, if people
> really want them (I hope not.)
> 
> Given that all of the routers within a domain are presumed to have the same
> policy, it seems quite sensible to declare that the router local to the
> problem is responsible for dealing with it.
> There is the argument that some mechanism would allow remote routers to
> cope with dumber local routers.  That is a complication too be avoided, as
> there are many ways for a local router to misbehave.  Second guessing
> another router in the same domain is just asking for trouble.
> 
> (The MANET situations i probably even more complicated, but remote flap
> damping does not strike me as the right answer then either.)
> 
> Yours,
> Joel M. Halpern
> 
> At 08:55 PM 1/4/2006, Erblichs wrote:
> >         If at the origination a "link" is decidely unstable, is
> >         their any disagreement that when the link comes up, the
> >         originator SHOULD advertise the link with an additionaly
> >         unstable penalty cost? It keeps the link available for
> >         no alternative routes versus doing nothing..