Re: [GROW] dampening

[Paul Francis <francis at mpi-sws.org>]

Christopher Morrow <christopher.morrow at gmail.com> wrote on 11/11/2009 
05:19:07 PM:

> From: Christopher Morrow <christopher.morrow at gmail.com>
> To: Paul Francis <francis at mpi-sws.org>
> Cc: Seiichi Kawamura <kawamucho at mesh.ad.jp>, grow at ietf.org, grow-
> bounces at ietf.org
> Date: 11/11/2009 05:20 PM
> Subject: Re: [GROW] dampening
> 
> On Wed, Nov 11, 2009 at 2:45 AM, Paul Francis <francis at mpi-sws.org> 
wrote:
> > Thanks Seiichi,
> >
> > I googled around myself as well, and found
> > http://www.ripe.net/ripe/meetings/ripe-43/presentations/ripe43-
> routing-flap.pdf
> > as well as the original sigomm paper.
> >
> > The objections with RFP have almost entirely to do with inter-domain
> 
> 'RFP' or 'RFD' ?? (D I think you meant)

Yes, RFD (somehow RFP flies off the fingers....)

> 
> > effects.  The "damping" of a flapping VP-route is of course entirely
> > intra-domain, so earlier objections with RFP don't apply here.
> 
> hopefully you hold the VA routes up on something that won't flap :)
> though certainly if you have damping enabled and links from edge->core
> flap you/ll see this effect, no?

Yes, you should of course make sure your VP routes don't flap.  But there 
is a catastrophic situation you need to avoid in case there is flapping. 
The problem would happen if your last VP route for a given VP is flapping 
(if you have multiple VP routes then one of them flapping won't cause the 
problem).  Say that there are 20K sub-prefixes in that VP.  When the VP 
goes away, all routers will suddenly want to load those sub-prefixes in 
FIB.  When the VP comes back, all routers will want to remove them from 
the FIB.  If the flapping happens at a fast enough rate, then basically 
your routers could find themselves constantly servicing the FIB.  So this 
is what we need to avoid.

This problem doesn't arise in the "VP-list" style of configuration that is 
in the current -01 version.  It comes about if we use tags to identify VP 
routes as a form of auto-configuration.

> 
> > Perhaps I should have chosen a different term than RFP in the talk.  I
> > took it for granted that people would see that it is a different 
situation
> > (RFP is meant to deal with frequently flapping remote links, I was 
merely
> 
> it's actually (D again, not P) meant to lower the CPU churn cost, no
> matter the source of the route update.

Right, but as above CPU churn isn't the issue here.  And because this is a 
different situation from normal RFD, it would probably be implemented 
differently.  (Though having said that I've considered to be a vendor 
local matter.)

> 
> > suggesting that a vendor implementing VA might need to take into
> > consideration the load that would occur if for some unfortunate reason 
an
> > ARP was flapping).
> 
> how would the device know a VA route from any other? 'community'? some
> other toggle/attribute? How do you disambiguate that from something
> set elsewere to the same value?

Well, this is what the ID-grow-va-auto-00 draft discusses.  There are a 
couple approaches in there, both of which involve a non-transitive 
extended community attribute what should only be used by routers 
internally so there should be no ambiguation anywhere.

PF


> 
> -chris
> 
> 
> > grow-bounces at ietf.org wrote on 11/11/2009 02:14:03 AM:
> >
> >> From: Seiichi Kawamura <kawamucho at mesh.ad.jp>
> >> To: grow at ietf.org
> >> Cc: jared at puck.nether.net
> >> Date: 11/11/2009 02:14 AM
> >> Subject: [GROW] dampening
> >> Sent by: grow-bounces at ietf.org
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> http://www.ripe.net/ripe/docs/ripe-378.html
> >>
> >> I think this is what Jared was referring to.
> >>
> >> Seiichi
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.9 (MingW32)
> >>
> >> iEYEARECAAYFAkr6D9sACgkQcrhTYfxyMkIS1gCgh5wRJdJbo4FLRebS5dHVjVoc
> >> Bz0An3x9x5BHs/ONey+HMxvjewq3KSTF
> >> =CLVe
> >> -----END PGP SIGNATURE-----
> >> _______________________________________________
> >> GROW mailing list
> >> GROW at ietf.org
> >> https://www.ietf.org/mailman/listinfo/grow
> >
> > _______________________________________________
> > GROW mailing list
> > GROW at ietf.org
> > https://www.ietf.org/mailman/listinfo/grow
> >