Christopher Morrow <[email protected]> wrote on 11/11/2009 05:19:07 PM:
> From: Christopher Morrow <[email protected]> > To: Paul Francis <[email protected]> > Cc: Seiichi Kawamura <[email protected]>, [email protected], grow- > [email protected] > Date: 11/11/2009 05:20 PM > Subject: Re: [GROW] dampening > > On Wed, Nov 11, 2009 at 2:45 AM, Paul Francis <[email protected]> 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 > > > > [email protected] wrote on 11/11/2009 02:14:03 AM: > > > >> From: Seiichi Kawamura <[email protected]> > >> To: [email protected] > >> Cc: [email protected] > >> Date: 11/11/2009 02:14 AM > >> Subject: [GROW] dampening > >> Sent by: [email protected] > >> > >> -----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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/grow > > > > _______________________________________________ > > GROW mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/grow > > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
