bad routing

[Bob Fink]

Rob,

I certainly agree with most of what you say. Getting the 6bone backbone as
stable and production oriented as possible is very important and I will
continue to push and support efforts to make it so.

Hopefully at the IETF next week we can address this:

First, at the NGtrans meeting when we talk about your current HARDEN draft:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-harden-02.txt>

Second, at the IPv6 Operational Topics meeting (day yet to be announced).


See you in DC, and thanks for pushing on this.

Bob


===
At 05:09 PM 11/3/99 -0500, Robert J. Rockell wrote:
>Forewarning: if you are going to be offended by seeing your own AS in this
>mail, do not read any further.
>
>
>I will use my own example, so as to not affend anyone, but I did want to
>mention something more regarding Ivano's mail about poorly aggregated
>prefixes.  Please consider the following excerpt from yesterday's report:
>
> SPRINT (3ffe:2900::/24) had 10 route(s)
>    3ffe:2900:1::18/126 path 1225 1849 5539 4556 ( -- 100%)
>    3ffe:2900:c:8::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%)
>    3ffe:29a1::/64 path 1225 1103 786 1849 3251 1930 1251 4270 11008
>    3ffe:2900:1::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%)
>    3ffe:2900:ffe3::/48 path 1225 1103 1200 8251 8731 8319 6175 7838 (USAA
>    3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 100%)
>    3ffe:29a1:c::/48 path 1225 1103 786 1849 3251 1930 1251 4270 11008
>    3ffe:2900:c005::/48 path 1225 1103 1200 8251 8731 8319 6175 11017 ( --
>    3ffe:2900:9::/48 path 1225 1103 1200 8251 8731 8319 6175 71 (HP -- 93%)
>    3ffe:29a2::/32 path 1225 1103 1200 8251 8731 8319 6175 11261 (ASCI --
>
>Looking at these, one may think "wow, Sprint sure is bad at aggregating it's
>prefixes".  However, if you look at this, one can see that SPrint's ASN
>(6175) is only in four of these BAD routes' AS path.
> 
>3ffe:29a2::/32
>3ffe:2900:9::/48
>3ffe:2900:c005::/48
>3ffe:2900:ffe3::/48 
>
>
>Now, as these do have Sprint in the AS path, we can see that the next AS in
>the path is both accepting these routes, and propogating them back up. AS
>8319 is a peer of Sprint, and Sprint is sending more specifics, and breaking
>aggregation rules.
>
>This has been fixed. However one may argue that AS8319 could filter more
>specifics from sprint, and help to alleviate this problem. I have adjusted
>my outbound filters to compensate.  SPRINT is at fault, but the upstream who
>allowed them shares blame (AS8319).
>
>The theory that filtering is bad because it does not show bugs in your
>system is no longer valid. If your IPv6 node is a single router, then you
>shoudl not be a pTLA, but a leaf node. One's internal network should suffice
>to test implementations. This way, it does not affect the rest of us.
>
>Every other route in this case does not even have Sprint in the AS path,
>which means someone else (usually the Sprint downstream) is leaking the route
>back up to their other upstreams.
>
>We have been trying to curtail this since orlando IETF.   
>
>It is the fault of the upstream provider to allow these announcements out,a
>nd the fault of EVERY PTLA in the AS path to allow these prefixes to be
>transitted. If you cannot filter, then give back your pTLA please.  This is a
>testbed, but this is not a lab.   You affect others when you break
>aggregation.  I will be glad to give you a transit connection, and some IPv6
>space to play.
>
>
>I will be contacting each of my downstreams who are leaking bad routes, and
>helping to get this fixed. If you have a lot of customers, please do the
>same. People who are on the bad rotuing report more than usually are not to
>blaim for most of the  bad rotues. It is their downstream customers other
>providers who have the problem. 
>
>MERIT: Woudl it be possible to jog this report to start blaiming the AS who
>is at fault, rather than the pTLA who cannot fix it?
>
>
>The worst offenders:
>
>AS 4555
>AS 7680
>AS 11008
>AS 2852
>
>IF you have these customers as direct downsteams, please filter them, for
>the sake of the rest of us.  
>
>Bob, perhaps we need to start actively policing this. I can see people on
>the bad routing report who have been there since I first heard of IPv6, and
>still refuse to filter. I will begin to take action on my pTLA. I encourage
>the rest of you to do so as well. Write to me personally if you do not nkow
>how/what to filter, and I can point you somewhere to learn.
>
>
>
>
>
>
>
>
>
>
>
>
>Thanks
>Rob Rockell
>Sprintlink Internet Service Center
>Operations Engineering
>703-689-6322
>1-800-724-3329, PIN 385-8833
>Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne?