Bad routes update

[Bob Fink]

6bone list in general,

Time for a long email on both the hardening effort and this very tough
multihoming issue and how it relates to the 6bone. Note, I am not claiming
to be an expert on either routing or multihoming problems (v4 or v6),
rather I'm trying to steer the 6bone activity so the v6 community gets the
most out of it.

The intent of Rob Rockell's "6bone hardening effort" draft
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-harden-00.txt> is
to make the 6bone more operationally robust, and (unstated) to make sure
the 6bone operates in the manner that the IPv6 development and standards
community envisions with the Aggregation based unicast addressing format
that established the TLA concept.

>From the draft:

>1. Abstract
>
>The 6Bone is an Ipv6 testbed to assist in the evolution and deployment  
>of IPv6. Because of this, it is important that the core backbone
>of the IPv6 network maintain stability, and that all operators have
>a common set of rules and guildelines by which to deploy IPv6 routing
>equipment. This document provides a set of guildelines for all IPv6
>routing equipment operators to use as a reference for efficient and stable
>deployment of IPv6 routing systems. As the complexity of the 6Bone grows,
>the adherence to a common set of rules becomes increasingly important in
>order for an efficient backbone to exist.

Regarding making the 6bone operationally robust, the current state of
routing policy (or lack thereof) combined with some sites that often don't
take adequate responsibility to configure and operate for reliable
production operation, leaves the 6bone very difficult to use for any real
production use. Though some parts of the 6bone world, say in Japan for the
WIDE project, run production, most don't do anything other than trade
routes and pings (and not too well at that). Please don't be offended if
you really do get production use out of your piece of the 6bone as I'm
referring to the larger whole (and what many of us observe from the traffic
we see).

I would venture to say the longer term aspect of an end-user site surviving
an ISP (pTLA) outage is not the primary issue at this time (yes, it's very
important for the future). Rather, just making a simple 6bone work
consistently and reliably is a first order high priority. Much work is
going on in this regard from the 6REN/6TAP to Rob's Hardening effort
(sanctioned by the 6bone/ngtrans community by the way).

So to the first order what Rob has proposed (and presented to the list and
in Oslo) are good engineering procedures to make a useful 6bone backone for
reliable operation.

Secondarily, we have a role related to the IPv6 development and standards
community to provide a viable testbed (proving ground) for ideas related to
future backbone operation. Having a coordinated effort to support this is
very important.

Everyone has recognized the problem with multi-homing in v6 for quite a
while, especially those folk participating in the IPng WG for the last few
years. I would generally characterize their view about the multi-homing
problem as it being a very hard problem, yet necessary to tackle or we will
have every /48 v6 prefix propagated in everyone's routing table.

So what to do. First and foremost, the IPng community is now focusing on
the multi-homing problem. There was a small team that decided to tackle it
between Minneapolis and Oslo, offline to the WG, who then reported on their
efforts to the IPng WG last week in Oslo. It is now viewed by the IPng WG
as the highest priority work going on and there will be a multi-day IPng
interim meeting on it before the Washington IETF meeting. Stay tuned to the
ipng list for reports and info on all this.

So, we need a 6bone that helps with this effort in the best way possible. I
believe that this means we agree to operate the 6bone backbone with rules
that are consistent with the current agreed IPng WG procedures as opposed
to just polluting our routing tables with everyones' routes.

Certainly one model for the 6bone (often suggested, I believe) is one of
real world operation (and competition) determining how it will work. I can
see that model possibly working in a real thriving fee for service
competitive IPv6 ISP world but we aren't even close to that point yet.
Also, we are less clear on many solutions to our problems yet, which is why
IPng work is underway on multihoming. So we need some discipline and method
to what we will try to do on the 6bone backbone.


Thus I propose that we, for now, implement Rob's proposed hardening rules
and don't try solve the multihoming issue by ad hoc methods for now. Then
we review the current ideas and proposals coming out of the IPng WG on this
over the next several months and entertain proposals for modifications to
our operating policies as necessary to try out new multihoming techniques
on the larger scale 6bone backbone. I definitely believe that to just allow
all routes to be accepted will lead to problems and certainly not to any
good long term solutions.

Soon enough, if we are wrong about how much we can do to solve the v6
multihoming problem, we can revert to the methods used in the v4 world.
Meanwhile I hope we will not only have a reliable backbone, but one that
can support new ideas from the v6 development and standards community.


I also agree with Rich Draves that debate on actual multihoming issues
should move to the ipng list as they are working it there, leaving just the
6bone related stuff on the 6bone list. This is not to stifle the list at
all, rather to get those working on multihoming maximally involved in the
discussions.


I hope you will agree to support some version of what I've described above
so we can move ahead.


Comments to the list please.

Bob