Bad routes update

[Masaki Hirabaru]

>> 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.

My comments on draft-ietf-ngtrans-harden-00.txt:

  < 3.9 Inter-site links

  < Global IPv6 addresses must be used for the end points of
  < inter-site links.  In particular, IPv4 compatible addresses
  < MUST NOT be used for tunnels.

  < Prefixes for inter-site links MUST NOT be injected in the
  < global routing tables.

1) I don't understand why this has to be mentioned. There may be
a inter-site link without global addresses. I think that this is
a matter local to the peers, and we don't have to limit possible
solutions.

2) This document focuses on prefixes so I'm not sure this should
be included: a pTLA should use the RFC version of BGP4+ (RFC??).

  < 4. Routing Policies

>> 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.

3) About multi-homing. As you mentioned the current agreed IPng
WG procedures, is limiting to /24 and /28 a requirement that
comes from IPng WG? Or, is it expressing that 6bone doesn't
accept any other solutions which may require even a little bit
relaxed rules?

I personally agree to pursue solutions that conform to this
routing policy, but I think that the discussion/deployment is
still on-going in IPng WG. I'd like to clarify the position of
6bone.

Thanks,
Masaki