No subject

[Alain Durand]

I have the feeling that we reach a rough consensus on the 6-bone topology,
i.e. some core/backbone nodes and some clouds connected to them.

In the next diagram :
	- a net is native IPv6 link
        - an island is a collection of ipv6 nets
	- a Core is core/backbone ipv6 node.
        - v6 means native IPv6
        - v4 means IPv6 encapsulated in IPv4



        v6         v6       v4
net132----island13----Core1----Core2
                        |  \  /  |
                        |   \/   |                   v6
                        |   /\   |                  ___ net475
                        |  /  \  |   v6            |
                      Core3----Core4----island47---|
                                           |       |___ net473
                                           |
                                         v4|            v6
                                           |__island48_____net484


Core4 is very close to the current situation of the G6-bone
and I believe to the other nodes of the 6-bone.

The question now is how to route packets from net475 to net132
and from net473 to net484

In my opinion, those are two different problems.
It's really interior routing versus exterior routing.
In the G6 bone, we plan to use RIPng inside islands. Maybe with some
manual configuration, we can extend it to route among our islands.

I have the feeling that doing RIPng to announce every single route
other the global 6-bone will simply not work. We need to agregate.
Doing dynamic external routing seems to me a bit premature. We can
still do a good job wit static routes if we take some precautions.

If there could be one common prefix to everything behind Core X,
then this will be very easy to do staticaly, and things could grow.
If they are many prefixes, it's going to be more difficult.
What I'd like to have on Core routers will be a simple external
routing tables like:
	5f-prefix1::/prefixlen1  -> Core1
	5f-prefix2::/prefixlen2  -> Core2
	5f-prefix3::/prefixlen1  -> Core3
	5f-prefix4::/prefixlen2  -> Core4
	...

To maintain those routing tables, a simple registry will be enough.

I see a little problem with RFC1897 address format, mainly because not all
islands behind Core X will have the same ISP, thus not the same prefix.

If we want to stay close to RFC1897, I see 3 solutions:
	a) use a special AS number for all Core X different from the ISP ones
	b) use the AS number of Core X ISP for all nets behind Core X
	c) have a Core node per AS number participating to the 6-bone.

If we agree an a scheme like this one, things could grow smoothly & quickly.
We could test both dynamic routing & hierarchical routing.

	- Alain.