Routing to ARIN from Teleglobe (2001:5a0::/32)

Andrew Alston aa at
Sun Feb 11 20:15:20 CET 2007

Ok I've been sitting this thread, and here are some thoughts:

I'm not even going to get into the technical merits and disagreements of
this debate, I am however going to say the following, this thread as of this
last post seems to be degenerating from a rational question that was
originally posed, asking for a simple fix, to one of accusations with some
harsh condescending overtones in it. So at this point, I wanna ask, are we
attempting to discuss (and fix) problems on this list, or are we going to
sit here and make accusations about who is "trying to bullshit" who?

If there is a problem with Occaid, I've generally found them to be VERY open
to rational discussion and fixing things with simple requests, infact I've
never had any grief from them whatsoever, has anyone actually bothered to
email them and get comment from them about the problem and perhaps present
that comment to the list?  Or are we all going to sit here ranting without
ever informing noc at of the problem?

Can we please avoid letting this degenerate into a mud-slinging match,
that's generally not a good way to solve problems, it is a good way however
to lose credibility.


Andrew Alston

-----Original Message-----
From: at
[ at] On Behalf Of
Bernhard Schmidt
Sent: Sunday, February 11, 2007 8:40 PM
To: Randy Epstein
Cc: ipv6-ops at
Subject: Re: Routing to ARIN from Teleglobe (2001:5a0::/32)

On Sun, Feb 11, 2007 at 12:43:11PM -0500, Randy Epstein wrote:

> > right in this thread.
> So C&W is leaking the prefix to Teleglobe.  OCCAID will need to take that
> with C&W.

I'm counting on that. Please talk to Tiscali as well while you are at
it, they are leaking prefixes as well:

2001:5e0::/32		1273 3257 30071 8121 16713

and about seven more, probably from filters on the C&W-OCCAID session
not being updated. Should Tiscali forward those prefixes to C&W since
they are an OCCAID peer?

Oh, and why should C&W give (and OCCAID accept) paths like

2001:4480::/32		30071 1273 6453 24724 9085

hrm, damn, there is a prefix going C&W-Teleglobe, wasn't that an issue

> > Can this be confirmed from someone within OCCAID? If yes, why are they 
> > being sent by C&W and Tiscali to their peers? And why does OCCAID take 
> > paths like "30071 3257 8767" (8767 <-> 3257 is a peering, just like 
> > 6453 <-> 3257) then? The story of not getting a full transit anymore 
> > does not match up with any sources I have.
> 8767 (M-net), according to their registered AS object, receives full
> from 3257, not simply peering:

I received confirmation, that is a documentation problem on behalf of
AS8767, since 3257 does not seem to have a decent as-set to have listed
here. Tiscali announces it's customers to the DE-CIX Routeserver for
example, compare 2001:a60::/32 (peering) with 2001:1a50::/32 (Transit)
on , or check paths.

> > I don't think any network is able to be transit-free in todays IPv6, 
> > as there is no tiered structure among the ISPs today. If there was, an 
> > R&D network with presence in US (and a little bit in Europe) would 
> > certainly not be in the position to be transit-free.
> Funny, there are a number of IPv6 networks that feel the same way, with a
> smaller network and traffic level than OCCAID.  I don't think you or I are
> to judge this.  I think OCCAID and the few that are not peering with
> need to work this out.

I really wanted to point people to the missing prefixes as root-cause at
first, but reading these things I sincerely do hope that the two
networks that actually give transit to OCCAID (I received some
out-of-band verifications in the mean time) stop so as soon as possible
(no need to give something away for free if you don't even get credits,
eh?) and let them have their transit-free network.

The last information (from OCCAID directly) was a community modification
had gone bad and that was the cause for the missing prefixes. Was that a
lie and OCCAID moved for transit-free five months ago?

> > Exaggeration, I apologize for that. Let's say ~25%, and don't start 
> > telling me those were badly connected ASNs (France Telecom, Teleglobe).
> If they can't reach OCCAID, which has a very large user base and content,
> then yes, they are badly connected.  25%?  Sorry, I think we can both see
> there are approximately 33 prefixes that OCCAID does not have in their
> that can be resolved with 2 or 3 additional peers.

You are looking now, not yesterday (or the months before). Stop trying
to bullshit me.

May I ask whether you are in any way affiliated with OCCAID? You seem to
have some internal knowledge here.


More information about the ipv6-ops mailing list