a 6bone topology discussion

[Bob Fink LBNL]

The recent spurt of new tunnels and various email traffic about it make me
want to comment on what I think we should be doing about the 6bone's
topology and routing.

Alain Durand has raised the question of whether we organize the 6bone's
tunnels on a geographical basis or based on the underlaying IPv4 networks.

Ran has also voiced concern for how routing information is passed on up the
chain, thus propagating bad routes/loops...and has also expressed advocacy
for a 6bone topology based on IPv4's.

At this time everyone is simply deciding to connect to the 6bone via
tunnels in what appears to me to be on a random basis.  If we are to
accomplish something of value as a testbed we should be organized and
methodical about our goals, what we are testing, and how we go about it.

Although I would like to say that we should adapt our topology entirely to
IPv4's, at least for now, that is hard to do everywhere as we have many
places where it is not possible.  For example, it is clearly useful for
some sites that are not ISPs (say Bay, Cisco, Digital, NRL) to provide a
place to tunnel to for their own testing purposes, for their early
customers and/or simply out of being a good Internet "neighbor").

I don't think we should discourage this for the sake of artificial IPv4
topology mapping.  Yet we do want to avoid gratuitous topology that moves
packets inefficiently.  We also want sensible routing, and even useful
testing of routing.


Thus I would propose that we adopt the following:

1.  Agree among us who the "core" backbone sites are, based on them either
being an ISP (e.g., WIDE, JOIN, G6, ESnet, CICNet) or someone seriously
committed to simulating one, at least for this phase of the 6bone (e.g.,
Bay, Cisco, Digital, NRL).

2.  These core sites would then decide how to interconnect among
themselves, i.e., tunnels and routing, based on what makes sense for
performance and reliability, and maybe even for the sake of testing routing
protocols as appropriate.

3.  Identify intermediate backbone (transit) sites that can also serve to
interconnect leaf/stub sites, but who may not wish the full responsibility
or load of being a "core" backbone site. (This extra work may be heavier
duty routing or policy enforcement.)

4.  These transit sites would then decide how to connect with one, or two
at the most, backbone sites based on agreement with those sites.

5.  Leaf/stub sites would then request a tunnel of a transit or backbone
site based on the IPv4 topology as much as possible.  The goal would be to
not traverse the world just to get across town (so to speak) if there is a
practical choice just across town.

6.  These leaf/stub sites would have only one, or two tunnels at most, to
minimize complexity.  The backbone/transit site(s) providing the tunnel
support would enforce routing policy down to the leaf/stub, i.e., make sure
the leaf/stub site understands the rules and disconnect the tunnel when
there is a problem or violation of policy.

7.  Leaf/stub sites don't set up tunnels among themselves, at least not
without real announcement and discussion to the list of intent and purpose,
and hopefully agreement from the list.


I appreciate that the above might be a lot to swallow, but at least we
should discuss what this might mean and decide to use it or develop a
different model.

If we don't, my concern is that we will have a poorly structured mess that
won't be of any use as we move ahead to the next more difficult test phases
of IPv6.

We have come so far with the 6bone to not want to preserve and enhance it!


Comments please - I just want to move ahead :-)


Thanks,

Bob