On Sun, 13 Feb 2005, Michael Smith wrote:
From: "Warren Kumari, Ph.D, CCIE# 9190" <warren@kumari.net> On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote:
That and the "I have 1 circuit to $good_provider and 1 circuit to $bad_provider and the only way I can make them balance is to split my space in half and announce more specifics out through each provider" argument. I have also often seen people do this without announcing the aggregate because <some undefined bad thing> will happen, usually justified with much hand-waving. The people who do this can usually not be reasoned with....
So, say I'm a provider that has received a /22 from UUNet (just for example Chris :-) ) and I now get another transit provider and announce the /22 there. So, I call UUNet and ask them to announce the /22 as a more specific
Meaning you have PA space from UUNET, and you have BGP so you can multi-home... I'd expect you to know how to deaggregate yourself. You MIGHT even know how to send no-export on deaggregated prefixes, or use the 1996 policies to influence preferences/prepends internal to 701, yes?
because I don't want a de-facto asymmetric configuration. I *want* to get a /20 from ARIN but my usage doesn't justify it yet, so I have to ride the /22 for some time.
I'm not clear as to how the /22 to /20 discussion goes, or how it's even relevant... but it's been a long day. Can you elaborate?
By the long string of anecdotal attacks in the string to date, listing most or all such providers as "bad" or "uninformed" how do you separate out those providers who are legitimately interested in routing redundancy and not clue
a /22 in both directions seems like safe 'redundancy'. Adding no-export /24's or /32's if you want (yuck) would get you more preference inside one provider or the other. I'm also fairly sure I didn't say: "bad" or "uniformed" the 'bad provider' is from Warren, not I.
impaired? Do we just say "too bad, routing table bloat is more important than your need for redundancy small guy!"?
I think that folks have been pushed toward multihoming with multiple providers (not just 'redundant T1' or 'shadow T1' services inside the same provider) over the last few years. That means some bloat is bound to occur. I'm not measuring it myself, but the renesys folks and LCS folks have been I think? Perhaps they can comment on that phenomenon?
I find it interesting that the general theme is one of "we're smarter than they are because we aggregate more routes" as if clue were directly correlated to aggregated routing announcements.
it's not? :) (joking of course) As I said before some folks feel they have a legitimate reason for deaggregating. If you can spend some time chatting them up about their reasons and either: 1) realizing they hav a point 2) re-purpose their thoughts toward 'better cidr management' (as pfs said) then good for you... and everyone else :) I have spent sometime on occasion doing this, sometimes it works out, othertimes it doesn't :( It's always an experience though. -Chris