Bad routes update

[Masaki Hirabaru]

Hi. Bob and all,

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

Do you really think enforcing the routing policy leads to
hardening (solving the current routing issues)?  It will cut a
couple of multi-homed sites to make the 6bone topology simple and
decrease the number of routing table entries from ~200 to ~170 as
well as other bogus routes by a few. But, I don't think it will
help to improve the current state of routing reliability.

Introducing the routing policy at each pTLA routers increases the
complexity of 6bone routing (in configuration by hand).  Before
practicing the complex routing policy (that may be called a
real-world practice), don't we have a couple of things to do?

1) Still a couple of pTLA sites are using the obsolete BGP4MP
version incompatible to the RFC version of BGP4MP. The problems
are that this is undocumented (since it's been obsolete) and that
it can not be automatically detected. It would happen easily to
configure the both sides with the different versions. A BGP
session can be established, but the update formats are different.

2) There are a lot of route flapping even within the valid pTLA
space.  A long time ago, I tried to figure out the origins, but I
gave up to continue it for all the occasions. It keeps happening.

3) There are a couple of strange routes outside the 6bone pTLA
space drafting over the 6bone. We could get it covered by
imposing the routing policy rather than solving the real problem.

Masaki

>> From: Bob Fink <fink@es.net>
>> Subject: Re: Bad routes update
>> Date: Tue, 20 Jul 1999 16:22:34 -0700
>> Message-ID: <4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net>
>>
>> 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