Re: Communities

["E.B. Dreger" <eddy+public+spam () noc everquick net>]

> Date: Mon, 15 Oct 2001 19:56:02 +0200 (CEST)
> From: Iljitsch van Beijnum <iljitsch () muada com>

(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 <blacklist () brics com>
To: blacklist () brics com
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 <blacklist () brics com>, or you are likely to be blocked.