|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Communities
> Date: Mon, 15 Oct 2001 19:56:02 +0200 (CEST) > From: Iljitsch van Beijnum <[email protected]> (This is more like two messages in one... I'm posting as a single message in sort of a "self digest" mode.) [ snip ] *** Message #1 *** > I don't understand what you mean. Redistributing upstream > routes where/into what? How can this be "despite" as-path > length? Hypothetical example with real names: Let's say that I have transit from 6347 and 2914. Now let's say that I'm stupid, and start advertising routes that I learn from 2914 into 6347, and that 6347 isn't filtering my as-paths or netblocks. [Note: 6347 does know better in the real world.] Now a customer ("Network X") of 6347 and 1239 will see 2914 netblocks via 6347 19358 2914 6347 { 701 | 1239 | 3561 } 2914 1239 2914 assuming that: + 1239/2914 directly connect + 6347/2914 do not directly connect + 6347 obtains transit to 2914 via 701, 1239, and 3561. 6347 learns 2914 routes from 701; 1239; 3561; and (wrongly) me, 19358... then chooses a best route to redistribute. Because 6347 sells transit to me, they'll give my routes higher local-pref than their peers or upstreams. Thus, for any 2914 netblock, I become the preferred egress from 6347. Problem #1. Now lets say that Network X uses local-pref to penalize _1239_.*_2914 Network X sees: 6347 19358 2914 1239 2914 Network X's local-pref policies in their route-maps makes the latter one undesirable. Problem #2, and the [extreme] example in my prior post. Some old-timers help me out: IIRC, 3561 got blackholed in 1997 by bad BGP from another well-known network... but I don't want to say more in case my memory is bad. *** Message #2 *** > Well, let me provide a real-world example. It's not really > congestion, but close enough for these purposes. > > When Telehouse had problems in Manhattan after the attacks on [ snip ] > So a community that indicates "you don't want to use this route > unless you absolutely have to--trust us" would have been very > welcome. Such a community would be especially useful in the > face of congestion: I see and agree. Good idea, IMHO. > But is it worth the trouble to try to "standardize" communities > for this? I should think that this would be trivial. 0x0000:* and 0xffff:* are reserved per RFC1997... release a new RFC with your "you don't want this route!" communities added, participants would benefit, non-participants would observe no change, and there would be no interoperability troubles. I think I like this better than my prior geography-based post... you're suggesting that MED-like info be advertised via standard communities. And who would know better than the originating provider? Makes sense to me... Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <[email protected]> To: [email protected] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[email protected]>, or you are likely to be blocked.
|