[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

database of the available tunnels

>>>>> "bound" == bound  <[email protected]> writes:

    bound> For those who want this to be a closed process lets not let
    bound> them do that and if necessary we can set up a routing
    bound> network around them.


i do share your global connectivity goals but i believe that the main
problem with the 6bone is that everybody has been "routing around
them" from the start. And it is not working too well.
We've have, as far as i understand, several groups that manage routing
information with little or no coordination among them.

It will be also useless to try to finger point people for the current
state of afairs. Personally, i believe we all have our share of
resposability on it.

My proposal is that we stablish an informal set peering etiquete rules.

    bound> There is nothing wrong with multiple sites routing packets
    bound> for everyones tunnels.

No, nothing wrong it that as long as routing information is
consistent. I doubt that currently that will be the case.

My proposal for peering rules:

a) Either a site runs default only to it's peer or it should
distribute, on every update, a copy of it's routing table to everybody
that peers with it. The idea is that you can run a distance vector
algorithm this way (we should agree on the format for this files so
that we can run scripts on them).
Better yet, we can add path information to the routes exported this
way and you have, in essence, a path based routing algorithm.

b) Non default sites should deposit regularly a copy of their routing
table and peering information on a well known place (RIPE or whatever).

c) A site should not limit trafic unless it clrearly states so in the
published information mentioned in b) (allow * policy by default)

    bound> In fact you may find eventually
    bound> some folks route IPv6 throught the tunnels faster and in
    bound> fact competition of this nature will foster better and high
    bound> performining implementations (again unlike the Mbone).

Ok agreed,
but instead of spliting in a miriad of different groups can we try,
at least once, to run *one* 6bone ?