Mailing List Archive

On Sun, 2005-06-05 at 11:05 -0500, eric wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Here's an interesting traceroute between two machines that are about 2 feet
> from each other (one on abilene and one on a he.net tunnel). Hopefully this
> will humor you folks as it does me. :)
>
> 1 2001:468:1202:301::1 2.879 ms 1.895 ms 1.713 ms
> 2 2001:468:1202::9 3.394 ms 3.265 ms 3.256 ms
> 3 2001:468:1202::5 4.394 ms 7.866 ms 5.066 ms
> 4 2001:468:1202::1 5.07 ms 5.164 ms 5.15 ms
> 5 2001:468:1200:3::1 5.381 ms 5.212 ms 5.227 ms
> 6 chinng-mren.abilene.ucaid.edu 5.494 ms 5.493 ms 5.657 ms
> 7 iplsng-chinng.abilene.ucaid.edu 14.709 ms 10.074 ms 9.316 ms
> 8 kscyng-iplsng.abilene.ucaid.edu 18.847 ms 19.099 ms 18.827 ms
> 9 dnvrng-kscyng.abilene.ucaid.edu 29.11 ms 29.003 ms 29.52 ms
> 10 sttlng-dnvrng.abilene.ucaid.edu 54.957 ms 54.879 ms 55.194 ms
> 11 2001:468:ff:16c1::6 221.706 ms 83.377 ms 187.573 ms

UCAID, hop 10-> is a tunnel that it increases latency by ~150++?

> 12 2001:320:1b00:1::1 324.767 ms 238.935 ms 238.597 ms
> 13 2001:320:1a02::b 216.856 ms 217.564 ms 217.258 ms

Kreonet (Korea)

Perfect example of their nice routeswaps

> 14 2001:220:400:200::1 217.181 ms 216.99 ms 217.108 ms
> 15 2001:220:1800:200::1 217.06 ms 217.725 ms 216.978 ms

Korea Telecom, this isn't educational...

> 16 3ffe:8140:101:1a::162 217.15 ms 216.913 ms 217.523 ms
> 17 3ffe:8140:101:1e::4 242.901 ms 238.166 ms 237.833 ms
> 18 3ffe:8140:101:6::3 217.382 ms 220.019 ms 217.338 ms

Japanese 6bone space

> 19 2001:200:0:1800::2516:1 217.192 ms 217.005 ms 217.372 ms

WIDE, Japan

> 20 v6-laix01.kddnet.ad.jp 330.397 ms v6-paix01.kddnet.ad.jp 334.4 ms
> v6-laix01.kddnet.ad.jp 329.04 ms
> 21 v6-nyix01.kddnet.ad.jp 416.347 ms 418.496 ms 418.725 ms
> 22 2001:458:26:2::500 310.786 ms 310.38 ms 310.375 ms

and back to the US..... jippie :)

> 23 2001:470:1fff:4:210:79ff:feea:e400 312.767 ms 315.092 ms 312.974 ms
> 24 ictus.catastrophe.net 381.949 ms 372.151 ms 392.789 ms
>
> Amazingly though, it's not as back towards abilene.
>
> 1 2001:470:1f01:ffff::876 59.078 ms 58.801 ms 60.573 ms
> 2 2001:470:1fff:2::26 58.739 ms 58.481 ms 58.795 ms
> 3 3ffe:80a::e 62.143 ms 62.793 ms 63.788 ms
> 4 3ffe:80a::bd 307.197 ms 307.225 ms 326.65 ms

There are your 300ms, ISI-LAP* 6bone space. Fortunately in 1 year + 1
day we won't have any 6bone junk left anymore.

Maybe Hurricane and Abilene could simply peer? :)

* =
8<--------------
ipv6-site: ISI-LAP
origin: AS4554
descr: LAP-EXCHANGE
Los Angeles
country: US
prefix: 3FFE:800::/24
tunnel: IPv6 in IPv4 bah.isi.edu -> Big number of World Wide
Sites....
-------------->8

I think they picked the 'bah' name on purpose, it is indeed quite
yucky...

Abilene would be a great travelagency btw, though show you the real
touristic route :)

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050605/4118525b/attachment.bin

On 5-jun-2005, at 18:33, Jeroen Massar wrote:

> Fortunately in 1 year + 1 day we won't have any 6bone junk left
> anymore.

That is nonsense, of course.

I see no reason to return my 6bone space (although I'm not going to
throw a hissy fit when my upstream takes it out of commission either).

More importantly, the existence of the 6bone has nothing to do with
bad routing. The reason this happens is:

- people who don't know what they're doing are allowed to muck around
with BGP in IPv6
- people who know what they're doing don't care
- hard to get native connectivity

Maybe we need some peering over 1 or 2 hop tunnels in places where
native peering can't be done for some reason.

On Sun, 2005-06-05 at 18:44 +0200, Iljitsch van Beijnum wrote:
> On 5-jun-2005, at 18:33, Jeroen Massar wrote:
>
> > Fortunately in 1 year + 1 day we won't have any 6bone junk left
> > anymore.
>
> That is nonsense, of course.
>
> I see no reason to return my 6bone space (although I'm not going to
> throw a hissy fit when my upstream takes it out of commission either).

Well you are going to if you like it or not:
http://www.ietf.org/rfc/rfc3701.txt

8<------------
It is anticipated that under this phaseout plan the 6bone will cease
to operate by June 6, 2006, with all 6bone prefixes fully reclaimed
by the IANA.
------------>8

Thus if you are using any 6bone prefix after 6/6/6 you simply are
hijacking address space.

Or the other very useful excerpt from above's RFC:
8<-----------
Thus after the 6bone phaseout date June 6, 2006, it is the intent
that no 6bone 3FFE prefixes, of any size/length, be used on the
Internet in any form. Network operators may filter 3FFE prefixes on
their borders to ensure these prefixes are not misused.
----------->8

> More importantly, the existence of the 6bone has nothing to do with
> bad routing. The reason this happens is:
>
> - people who don't know what they're doing are allowed to muck around
> with BGP in IPv6
> - people who know what they're doing don't care

Those two issues really apply to the problems occurring in the 6bone
networks., which in most cases are unmaintained by now and are simply
running on air.

> - hard to get native connectivity

There are enough places around the world where this can be done and
otherwise it is quite easy to set up a IPv6-over-IPv4 tunnel over the v4
infra that exists already. This still does not lead to routing over
Korea and Japan. That is caused by:

> Maybe we need some peering over 1 or 2 hop tunnels in places where
> native peering can't be done for some reason.

The problem with Abilene is simply Political Policies, they can't don't
play transit for certain parties who they do give some transit to and
then these routes are accepted sometimes over japense or korean NREN's
as they don't get them over their native peerings. See the list archives
and many other discussions on this topic*. But they claim afaik to be
working on it. In the meantime those prefixes are basically useless or
at least high on latency.

* = http://lists.cluenet.de/pipermail/ipv6-ops/2005-May/000128.html

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050605/c6d14928/attachment.bin

On Sun, Jun 05, 2005 at 06:44:03PM +0200, Iljitsch van Beijnum wrote:
> On 5-jun-2005, at 18:33, Jeroen Massar wrote:
>
> >Fortunately in 1 year + 1 day we won't have any 6bone junk left
> >anymore.
>
> That is nonsense, of course.
>
> I see no reason to return my 6bone space (although I'm not going to
> throw a hissy fit when my upstream takes it out of commission either).
>
> More importantly, the existence of the 6bone has nothing to do with
> bad routing. The reason this happens is:
>
> - people who don't know what they're doing are allowed to muck around
> with BGP in IPv6
> - people who know what they're doing don't care
> - hard to get native connectivity
>
> Maybe we need some peering over 1 or 2 hop tunnels in places where
> native peering can't be done for some reason.

With all due respect, let me correct you.

It is not the peering that you need. It is _transit_, _transit_, _transit,
and again, transit that you need.

There are too many people in IPv6 today who have near-zero experience operating
a real backbone in IPv4 that they think peering is all that need to run teir
v6 network. But no, they really need an upstream transit provider to make their
routing sane. Ask your upstreams to support IPv6 or ask around for a free
upstream v6 service whether delivered over tunnel or native. And stop giving
transit to your upstreams. Give them access to your own network and stop there.

Tunnel does degrade the quality of v6 as we all know, but its not the tunneling
that is killing IPv6's quality today. It is the lack of experience by people
thinking their network is Tier1 by throwing tunnels all around and full
swapping full routes over them. Abilene unfortunately is an example of full
swapped network over native peers (KREONET, APAN) (no offense at all for folks
from Abilene, but I'm just stating the cold observatory fact).

And as Eric posted in his initial post, you can see how bad routing can get
even with native "peers".

-J

--
James Jun
Infrastructure and Technology Services
TowardEX Technologies
Office +1-617-459-4051 x179 | Mobile +1-978-394-2867
james@towardex.com | www.towardex.com

On 5-jun-2005, at 19:00, Jeroen Massar wrote:

>> I see no reason to return my 6bone space (although I'm not going to
>> throw a hissy fit when my upstream takes it out of commission
>> either).

> Well you are going to if you like it or not:
> http://www.ietf.org/rfc/rfc3701.txt

> Thus if you are using any 6bone prefix after 6/6/6 you simply are
> hijacking address space.

I look forward to discussing the meaning of the word "hijacking" with
the IANA/ICANN lawyers.

>> - people who don't know what they're doing are allowed to muck around
>> with BGP in IPv6
>> - people who know what they're doing don't care

> Those two issues really apply to the problems occurring in the 6bone
> networks., which in most cases are unmaintained by now and are simply
> running on air.

In theory people using RIR space should at least have some basic
level of comprehension but as far as I can tell, this doesn't
immediately translate to better routing in IPv6.

>> - hard to get native connectivity

> There are enough places around the world where this can be done and
> otherwise it is quite easy to set up a IPv6-over-IPv4 tunnel over
> the v4
> infra that exists already. This still does not lead to routing over
> Korea and Japan.

Well, BGP may not be that smart, but generally, this shouldn't happen
if there is also more local connectivity.

> That is caused by:

>> Maybe we need some peering over 1 or 2 hop tunnels in places where
>> native peering can't be done for some reason.

> The problem with Abilene is simply Political Policies,

They don't want to buy IPv6 transit, which is a pity, but
understandable.

Having better peering would be a reasonable alternative for them and
networks of similar size.

Iljitsch van Beijnum wrote:
> On 5-jun-2005, at 19:00, Jeroen Massar wrote:
>
>>> I see no reason to return my 6bone space (although I'm not going to
>>> throw a hissy fit when my upstream takes it out of commission either).
>
>
>> Well you are going to if you like it or not:
>> http://www.ietf.org/rfc/rfc3701.txt
>
>
>> Thus if you are using any 6bone prefix after 6/6/6 you simply are
>> hijacking address space.
>
>
> I look forward to discussing the meaning of the word "hijacking" with
> the IANA/ICANN lawyers.

As nobody has obtained 6bone space without agreeing to give it back, I
really don't see an issue here. Everyone that has 6bone space has
agreed to the agreement. It will be returned, it will be useless after
6/6/2006. No amount of screaming and kicking is going to change that
and no amount of lawyers ;-)


Thanks,


--

Daniel Austin,
Managing Director,
Kewlio.net Limited.
<daniel@kewlio.net>

Iljitsch van Beijnum wrote:
> I look forward to discussing the meaning of the word "hijacking" with
> the IANA/ICANN lawyers.

I would suggest complaining to the entity that revokes your delegation,
not ICANN. If the 6bone project voluntarily returns 3ffe::/16 it's not
ICANN's fault. Actually it's nobody's fault since that was the plan
from day 1. Someone might pull off a temporary restraining order, but
that would only delay the inevitable.

When (not if) it is returned, it becomes bogon space until delegated
again. We seem to be doing a decent job of squashing bogons right now.
That is a good thing because the alternative opens the door to massive
abuse.

- Kevin

Heya,

> Maybe Hurricane and Abilene could simply peer? :)
>
> Abilene would be a great travelagency btw, though show you the real
> touristic route :)

I'm somewhat new to this list, but this is the second thread about Abilene
that I've seen which implies that Abilene provides crappy transit and should
increase its peering. I'm not sure if people on this list are aware, but
Abilene is not a transit ISP. It is a private network interconnecting research
institutions in the US, the US government and related organiztions, and other
international research networks. In our v4 BGP table, Abilene has about
16,000 routes whereas each of our transit providers has about 160,000. This
is intentional and, clearly, isn't considered a transit provider into the
Internet's default-free zone.

The University that I work for has several commodity transit providers as well
as a connection with Abilene. The reason why you are seeing horrible transit
via Abilene to the commodity v6 Internet comes from the fact that you are
trying to overlay a transit v6 service on top of a fundamentally non-transit
v4 infrastructure (transit in the Internet default-free zone sense). It may be
your only native v6 connectivity option, but you should be aware of the
limitations of that service (namely, what it is and what it is not).
Suggestions that Abilene increase its private peering with other transit
carriers is likely to fall on deaf ears, not because they lack the
understanding/funding/caring to build out a "tier-1" transit infrastructure,
but because its not what their network is intended or designed for.

If you're interested in this sort of thing, you might have better luck speaking
to the various gigapops directly or to the members of the quilt project
(thequilt.net), which is where a some of the Internet2/Abilene gigapop
institutions are looking to leverage some of their local Internet2/Abilene
resources for commodity internet services. Adding in native v6 peering into
the commodity v6 Internet at some of these gigapops might go a long way to
resolving your problems. (If someone is interested in this for the Boston,
MA/US area, drop me a private note).

Eric :)

On 5-jun-2005, at 21:25, James wrote:

>> Maybe we need some peering over 1 or 2 hop tunnels in places where
>> native peering can't be done for some reason.

> With all due respect, let me correct you.

> It is not the peering that you need. It is _transit_, _transit_,
> _transit,
> and again, transit that you need.

Well, _I_ have transit. :-) (Twice in fact, although it doesn't
allow me to multihome, being an end-user.)

> There are too many people in IPv6 today who have near-zero
> experience operating a real backbone in IPv4 that they think
> peering is all that need to run teir v6 network. But no, they
> really need an upstream transit provider to make their routing
> sane. Ask your upstreams to support IPv6 or ask around for a free
> upstream v6 service whether delivered over tunnel or native.

Free upstream is not worth the trouble. Either you don't really use
it, or you do, and it won't be there for long, or not be free for long.

> Tunnel does degrade the quality of v6 as we all know,

I'll take a direct tunneled route over an indirect native one any
day. What really kills us are _indirect_ tunnels, because the routing
protocols don't see how bad they are.

If tunnels are the fastest way to move IPv6 packets, why not use them?

> It is the lack of experience by people
> thinking their network is Tier1 by throwing tunnels all around and
> full
> swapping full routes over them.

:-)

I'm sure this happens, but in and of itself this is not all that
harmful. The problem is that others who should know better don't
filter out this "free transit".

On 6-jun-2005, at 15:47, Eric Gauthier wrote:

[a long message]

I'm sorry, but I really don't understand any of that.

All I know is that when I connect to a research IPv6 network (which
often happens at IETF meetings), I have huge difficulties connecting
to my stuff at home.

This is an example of how this works:

# traceroute6 chinng-mren.abilene.ucaid.edu
traceroute6 to chinng-mren.abilene.ucaid.edu (2001:468:ff:fc3::1)
from 2001:1af8:2:5::2, 30 hops max, 12 byte packets
1 2001:1af8:2:5::1 0.612 ms * 0.633 ms
2 2001:1af8:1:15:20e:39ff:fe3c:2aaa 18.208 ms 1.171 ms 1.015 ms
3 tunnel6.6bb1.AD1-Amsterdam.ipv6.teleglobe.net 1.776 ms !N 1.841
ms !N 1.555 ms !N

# traceroute6 chinng-mren.abilene.ucaid.edu
traceroute6 to chinng-mren.abilene.ucaid.edu (2001:468:ff:fc3::1)
from 2001:600:8:34::2, 30 hops max, 12 byte packets
1 6b2.ams7.alter.net 3.310 ms 2.541 ms 2.879 ms
2 tu2.6B1.FFT4.ALTER.NET 10.716 ms 10.259 ms 9.979 ms
3 tif-6bone2uunet-nl.ipv6.uni-muenster.de 36.405 ms 37.532 ms
37.129 ms
4 3ffe:1001:1:f011::1 52.695 ms 54.506 ms 52.553 ms
5 gw2-bk1.ipv6.tilab.com 50.835 ms 52.611 ms 52.163 ms
6 3ffe:1001:1:f017::2 232.032 ms 231.215 ms 231.097 ms
7 3ffe:80a::e 336.059 ms 333.151 ms 335.731 ms
8 3ffe:80a::bd 391.840 ms 384.990 ms 395.751 ms
9 dnvrng-snvang.abilene.ucaid.edu 408.757 ms 419.526 ms 447.008 ms
10 kscyng-dnvrng.abilene.ucaid.edu 420.447 ms 432.225 ms 423.243 ms
11 iplsng-kscyng.abilene.ucaid.edu 474.287 ms 452.181 ms 427.864 ms
12 *^C

In what universe does this make sense?

On Mon, 6 Jun 2005, Iljitsch van Beijnum wrote:

> All I know is that when I connect to a research IPv6 network (which often
> happens at IETF meetings), I have huge difficulties connecting to my stuff at
> home.

Hrm. Yes as a victom of that, I do sympathise. Is this worth discussing
at the next IETF v6ops WG, or is it beyond the IETF's scope? And if it
is, what are the venues, besides this mailing list?



wfms

On Mon, Jun 06, 2005 at 07:18:16PM +0200, Iljitsch van Beijnum wrote:
> I'm sorry, but I really don't understand any of that.
>
> All I know is that when I connect to a research IPv6 network (which
> often happens at IETF meetings), I have huge difficulties connecting
> to my stuff at home.

Eric's point is that it isn't Abilene's business to provide global
transit, but only an infrastructure between the connected members.
The "research IPv6 network" you connect to at IETF meetings should
have some IPv6 transit independent of Abilene.

Unfortunately, this doesn't really reflect reality out there, especially
not in the US. Some European NRENs do have commercial transits, but
most use GEANT/DANTE for that - which is also a... touchy topic.

So either Abilene shuts down the transits taken from KREONET2 and APAN
and thus force all connected RENs to look for transit elsewhere, or
get at least one sane transit somewhere in the US instead. This would
fix the odd routing problems we observe every now and then.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Hi,

On Mon, Jun 06, 2005 at 01:24:45PM -0400, William F. Maton Sotomayor wrote:
> On Mon, 6 Jun 2005, Iljitsch van Beijnum wrote:
>
> >All I know is that when I connect to a research IPv6 network (which often
> >happens at IETF meetings), I have huge difficulties connecting to my stuff
> >at home.
>
> Hrm. Yes as a victom of that, I do sympathise. Is this worth discussing
> at the next IETF v6ops WG, or is it beyond the IETF's scope? And if it
> is, what are the venues, besides this mailing list?

This is purely something Abilene needs to sort out. Either it is a
transit provider for the local research networks - or it isn't, but if
it isn't, they should stop announcing other people's routes all around
the place.

gert
--
Total number of prefixes smaller than registry allocations: 71007 (66629)

SpaceNet AG Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
D- 80807 Muenchen Fax : +49-89-32356-234

On 6-jun-2005, at 19:27, Daniel Roesen wrote:

>> I'm sorry, but I really don't understand any of that.

>> All I know is that when I connect to a research IPv6 network (which
>> often happens at IETF meetings), I have huge difficulties connecting
>> to my stuff at home.

> Eric's point is that it isn't Abilene's business to provide global
> transit, but only an infrastructure between the connected members.
> The "research IPv6 network" you connect to at IETF meetings should
> have some IPv6 transit independent of Abilene.

> Unfortunately, this doesn't really reflect reality out there,
> especially
> not in the US. Some European NRENs do have commercial transits, but
> most use GEANT/DANTE for that - which is also a... touchy topic.
>
> So either Abilene shuts down the transits taken from KREONET2 and APAN

Right. They can't have it both ways. Either they accept the fact that
they do provide transit and start working on improvements, or they
implement their policy and cut off all forms of de facto transit.

> and thus force all connected RENs to look for transit elsewhere, or
> get at least one sane transit somewhere in the US instead. This would
> fix the odd routing problems we observe every now and then.

If they accept that they provide transit for research networks
another option would be to start peering with important commercial
IPv6 transit providers.

On 6-jun-2005, at 19:24, William F. Maton Sotomayor wrote:

>> All I know is that when I connect to a research IPv6 network
>> (which often happens at IETF meetings), I have huge difficulties
>> connecting to my stuff at home.

> Hrm. Yes as a victom of that, I do sympathise. Is this worth
> discussing at the next IETF v6ops WG, or is it beyond the IETF's
> scope? And if it is, what are the venues, besides this mailing list?

The trouble is that the influence regular IETF goers have on the way
the IETF meetings are organized isn't statically different from zero.

It would be good if the IETF could get regular commercial or semi-
commercial (i.e., non-research) transit but that's not always easy to
find.

I think I'll start an IPv6 transit business and get rich. :-)

Iljitsch

Hi,

#I'm somewhat new to this list, but this is the second thread about Abilene
#that I've seen which implies that Abilene provides crappy transit and should
#increase its peering. I'm not sure if people on this list are aware, but
#Abilene is not a transit ISP. It is a private network interconnecting research
#institutions in the US, the US government and related organiztions, and other
#international research networks. In our v4 BGP table, Abilene has about
#16,000 routes whereas each of our transit providers has about 160,000. This
#is intentional and, clearly, isn't considered a transit provider into the
#Internet's default-free zone.

Abilene's IPv6 routing policies (and their IP multicast policies for that
matter) intentionally differ from their unicast IPv4 routing policies.

For official confirmation of this see Rick's presentation at
http://ipv6.internet2.edu/Internet2-IPv6-Update.pdf at slide 11
("IPv6 Peering Policy -- open peering policy, with transit if desired --
different from IPv4")

#The University that I work for has several commodity transit providers as well
#as a connection with Abilene. The reason why you are seeing horrible transit
#via Abilene to the commodity v6 Internet comes from the fact that you are
#trying to overlay a transit v6 service on top of a fundamentally non-transit
#v4 infrastructure (transit in the Internet default-free zone sense). It may be
#your only native v6 connectivity option, but you should be aware of the
#limitations of that service (namely, what it is and what it is not).

Of course, if the presumption is that sites should be multihomed for IPv6,
that implies a resolution of the IPv6 multihoming problem, a resolution
that I don't believe has happened yet unless you believe in the provider
independent allocation "solution" (which is inconsistent with IPv6's
hierarchical route aggregation goals, etc.)

#Suggestions that Abilene increase its private peering with other transit
#carriers is likely to fall on deaf ears, not because they lack the
#understanding/funding/caring to build out a "tier-1" transit infrastructure,
#but because its not what their network is intended or designed for.

Actually, Abilene has been extremely receptive to increasingly their IPv6
peering, and very responsive to particular suggestions, providing they have
infrastructure where they need it to make peering happen (and I say this
from first hand experience).

#If you're interested in this sort of thing, you might have better luck speaking
#to the various gigapops directly

<waves from the Oregon Gigapop> ;-)

#or to the members of the quilt project
#(thequilt.net), which is where a some of the Internet2/Abilene gigapop
#institutions are looking to leverage some of their local Internet2/Abilene
#resources for commodity internet services. Adding in native v6 peering into
#the commodity v6 Internet at some of these gigapops might go a long way to
#resolving your problems. (If someone is interested in this for the Boston,
#MA/US area, drop me a private note).

A number of the providers who offer commodity IPv4 service through TheQuilt
also offer IPv6, but then we come back to the multihoming issue.

Regards,

Joe

On Mon, Jun 06, 2005 at 07:37:07PM +0200, Iljitsch van Beijnum wrote:
> >So either Abilene shuts down the transits taken from KREONET2 and APAN
>
> Right. They can't have it both ways. Either they accept the fact that
> they do provide transit and start working on improvements, or they
> implement their policy and cut off all forms of de facto transit.

Correct. That's how I see it too.

> >and thus force all connected RENs to look for transit elsewhere, or
> >get at least one sane transit somewhere in the US instead. This would
> >fix the odd routing problems we observe every now and then.
>
> If they accept that they provide transit for research networks
> another option would be to start peering with important commercial
> IPv6 transit providers.

Peering doesn't make much sense in the non-transit case, as this doesn't
buy the Abilene participants much. Those need to buy commercial transit
anyway, and then those commercial upstreams can sort out the "good
connectivity to the world" issue - that's what they are being paid for.

One IMHO sensible scenario for Abilene could be:

- hook up to OCCAID (http://www.occaid.org/) and get transit there
- take only NREN peering routes from APAN/KREONET2, not full table
- announce only Abilene participant routes to APAN/KREONET2
- ask APAN/KREONET2 to not leak Abilene routes to any non-REN network

Abilene participants can then choose to use the OCCAID transit via
Abilene, or alternatively if that doesn't meet their requirements
(anymore), buy their own commercial transit.

That would accomplish three goals at once:

- get rid of the routing problems induced by the APAN/KREONET2 route
swaps

- have a sane transit (OCCAID) who actually localprefs and otherwise
would handle Abilene routes as _customer_ (downstream) routes

- provide sane free transit to Abilene and their direct participants
as "bootstrap connectivity" to replace the APAN/KREONET2
pseudo-transit

==> Abilene would leave the state of "reachable if you're lucky" and
become part of the production quality IPv6 Internet.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Hi Eric,

On Mon, Jun 06, 2005 at 09:47:36AM -0400, Eric Gauthier wrote:

[ snip ]

> resolving your problems. (If someone is interested in this for the Boston,
> MA/US area, drop me a private note).

Did you get my email earlier (few weeks back) offering you transit? I haven't
heard back yet so I just wanted to check in..

Thanks for your time,
James

--
James Jun
Infrastructure and Technology Services
TowardEX Technologies
Office +1-617-459-4051 x179 | Mobile +1-978-394-2867
james@towardex.com | www.towardex.com