[6bone] RFC 2772 input from RIR space holder

[Nicolas DEFFAYET]

On Wed, 2002-11-20 at 19:39, Jorgensen, Roger wrote:
Hi,

> Going to reply to Robert's mail that never got the attention it
> deserved. It is very important to understand why RIR space
> holders care about RFC 2772. 
> 
> We make living out of selling/providing services over Internet,
> we are totaly depended on what people call production quality
> or reliable routing. It's not just a word for us, it's our life 
> as a provider we're talking about. 
> We can assume that most of the services that will be important 
> from a business perspective will be using RIR space.
> Think we also can safely assume that RIR space are for 
> production services (as said above), and 6bone space used for
> experimental/learning/testing purpose.

A lot of ISP use their sTLA for experimental/learning/testing purpose.

> This isn't just the view of one single sTLA holder, it's a view
> I know is shared by many others.

Many others ?
Who are they ?

> How to create a stable IPv6
> network are The Focus for many big ISP's with sTLA right now.
> There are work in progress to create guidelines and later I 
> guess it might be an official document covering the routing
> issue in RIR space. We will sort ourself out...the issue is
> 6bone routing. We do NOT want 6bone to have ANY impact on our
> business at all. That's pretty much the bottom line. Robert
> outlined one way to gain this in his mail (see end of mail),
> the following part are a suggestion from me, it's  build on 
> the frame Robert outlined.

The problems (ghost routes, unstability, bad performances,..) are not
6bone specific.
This problems are just a pretext for don't have 6bone address in your
routing table. This problems must be solved. Circumvent a problem is
easy, resolve it is more hard.

Currently 6bone and RIR have the same network topology (a lot of tunnels
and very little native links) and there is not transit provider, the
only difference beetween 6bone and RIR are address type (pTLA/sTLA) in
routing table.


Now, we will imagine that the 6bone does not exist any more.

- There is not transit provider, you exchange a full table with your
peers. (no changes with 6bone)
- There is a ISP with a old routing software and this ISP generate ghost
routes. (no changes with 6bone)
- You peer with a lot of tunnel. (no changes with 6bone)

The ONLY change will be that you don't have 6bone address in your
routing table.

> It basically give us the chance to make a quality production IPv6 
> network AND still be able to do experimental stuff on 6bone without 
> impact on each other. it also give us (RIR) the chance to guaranty 
> routing in RIR space, or to say it as manager:
> 
> "we can provide production quality on our IPv6 network"

You will guaranty routing over tunnel ?
Tunnels offer bad and random performance.
You can own your fiber, control your IPv4 network, but you will have
always the tunnel encapsulation.

For provide a real production quality, you must have a native IPv6
network without tunnels.

Cut 6bone and RIR will be beneficial only if RIR have a lot of native
links and very little tunnels.


Best Regards,

-- 
Nicolas DEFFAYET, NDSoftware
NOC Website: http://noc.ndsoftwarenet.com/
FNIX6: http://www.fnix6.net/