Subject: RE: damping persistent peer oscillations

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 6 Dec 2002 14:01:10 -0500

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

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

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]] 
> Sent: Friday, December 06, 2002 1:33 PM
> To: Natale, Jonathan
> Cc: [email-masked]
> Subject: Re: damping persistent peer oscillations 
> 
> 
> 
> In message 
> <[email-masked]
> 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
>

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 06 Dec 2002 14:12:31 -0500

In message <[email-masked]
> 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?

> 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