Re: damping persistent peer oscillations

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Curtis,
> 
> Thanks for the reply.
> 
> But I was looking for *peer* oscillation damping, not *route* oscillation
> damping.  RFC1771 had:
> 
>     "For a peer that was previously transitioned to Idle due to an error,
> the time between consecutive generation of Start events, if such events are
> generated automatically, shall exponentially increase."

The text I quoted started with

  When a peer routing session is broken, ...

and suggested

  the peering session itself may be marked as unstable.

How is this not applicable?

> --Current implementations (AKA Juniper and Cisco) do not do this, and the
> draft-18 has it tagged as out of scope (see below).
> 
> Maybe this will be in the RFC1772 re-do and/or a BCP?

Since its out of scope but OK to do something as stated in -18, its OK
to do what is recommended in RFC2439 but not required.

You asked if anything addressed a "method of damping persistent peer
oscillations".  The answer is "yes there is".

Curtis


> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]] 
> > Sent: Friday, December 06, 2002 1:33 PM
> > To: Natale, Jonathan
> > Cc: [e-mail]
> > Subject: Re: damping persistent peer oscillations 
> > 
> > 
> > 
> > In message 
> > <[e-mail]
> > ks.com>, "Natale, Jonathan" writes:
> > > >From Draft 18:
> > > "Local system automatically starts the BGP peer connection 
> > with persistent
> > > peer oscillation damping enabled.  The exact method of 
> > damping persistent
> > > peer oscillations is left up to the implementation.   These 
> > methods of
> > > damping persistent BGP adjacency flapping are outside the 
> > scope of this
> > > document."
> > > 
> > > -- is there a draft describing a "method of damping persistent peer
> > > oscillations" ?
> > 
> > 
> > RFC 2439 "BGP Route Flap Damping":
> > 
> >   4.8.5 Processing A Peer Router Loss
> > 
> >    When a peer routing session is broken, either all individual routes
> >    advertised by that peer may be marked as unstable, or the peering
> >    session itself may be marked as unstable.  Marking the 
> > peer will save
> >    considerable memory.  Since the individual routes are advertised as
> >    unreachable to routers beyond the immediate problem, per 
> > route state
> >    will be incurred beyond the peer immediately adjacent to the BGP
> >    session that went down.  If the instability continues, the
> >    immediately adjacent router need only keep track of the peer
> >    stability history.  The routers beyond that point will receive no
> >    further advertisements or withdrawal of routes and will dispose of
> >    the damping structure over time.
> > 
> >    BGP notification through an optional transitive attribute that
> >    damping will already be applied may be considered in the future to
> >    reduce the number of routers that incur damping structure storage
> > 
> > Curtis
> > 
>