bad routing

[Robert J. Rockell]

I would agree with that :)

However, I believe that ipv6 backbone stability is going to be more than
just nice if we are to convince the mostly anti-v6 world that this stuff
works. If the "experts" can't make it work, how do we get the rest of the
world on board?  Big Business involvement is the key to IPv6's sucess. Big
Business is wary to change. If we can't show EXPLICIT improvement in IPv6
over IPv4, the transition will be delayed till the very end. I just don't
want to see this happen. Sorry if I strap my boots on a little to tight. I
think it is time someone did. If SPRINT did this in the Internet, we would
get killed on the NANOG mailing list... I think it would be nice if everyone
took this a little more seriously.  Sorry if I offend anyone.

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?

On Thu, 4 Nov 1999, rob wrote:

->
->Robert, you need to relax.
->
->
->-----Original Message-----
->From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of
->Robert J. Rockell
->Sent: Thursday, November 04, 1999 8:57 AM
->To: 6bone@ISI.EDU
->Subject: bad routing
->
->
->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?
->
->
->