Subject: [GROW] dampening

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 11 Nov 2009 10:14:03 +0900

http://www.ripe.net/ripe/docs/ripe-378.html

I think this is what Jared was referring to.

Seiichi

---

From: Jared Mauch <[email-masked]>
Date: Tue, 10 Nov 2009 20:17:44 -0500

This may also provide further guidance.

http://www.ietf.org/mail-archive/web/idr/current/msg01128.html

- Jared

On Nov 10, 2009, at 8:14 PM, Seiichi Kawamura wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> 
> iEYEARECAAYFAkr6D9sACgkQcrhTYfxyMkIS1gCgh5wRJdJbo4FLRebS5dHVjVoc
> Bz0An3x9x5BHs/ONey+HMxvjewq3KSTF
> =CLVe
> -----END PGP SIGNATURE-----

---

From: Paul Francis <[email-masked]>
Date: Wed, 11 Nov 2009 08:45:19 +0100

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 
effects.  The "damping" of a flapping VP-route is of course entirely 
intra-domain, so earlier objections with RFP don't apply here.

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

Next time I'll call it "FIB churn prevention" :)

PF

[email-masked] wrote on 11/11/2009 02:14:03 AM:

> From: Seiichi Kawamura <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Date: 11/11/2009 02:14 AM
> Subject: [GROW] dampening
> Sent by: [email-masked]
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Nov 2009 11:19:07 -0500

> The objections with RFP have almost entirely to do with inter-domain

'RFP' or 'RFD' ?? (D I think you meant)

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

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

> consideration the load that would occur if for some unfortunate reason an

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?

-chris

---

From: Paul Francis <[email-masked]>
Date: Wed, 11 Nov 2009 21:29:33 +0100

Christopher Morrow <[email-masked]> wrote on 11/11/2009 
05:19:07 PM:

> From: Christopher Morrow <[email-masked]>
> To: Paul Francis <[email-masked]>
> Cc: Seiichi Kawamura <[email-masked]>, [email-masked], grow-
> [email-masked]
> Date: 11/11/2009 05:20 PM
> Subject: Re: [GROW] dampening
> 

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

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

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

> 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