Bad routes update

[Robert Rockell]

Please send comments. I have just submitted -01.txt, so see that soon. I
will give two weeks, and submit -02.txt

Changes: added statement regarding 6to4 (kept ambiguous so as to not impede
its development, from a routing perspective). 

Added in a statement about multi-homing directly, to indicate future
flexibility should the multi-homing solution need testing.

Thanks
Rob Rockell
Sprintlink Internet Service Center
Operations Engineering
703-689-6322
1-800-724-3329, PIN 385-8833
Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne?

On Wed, 21 Jul 1999, Bob Fink wrote:

->Masaki,
->
->At 01:53 PM 7/21/99 -0400, Masaki Hirabaru wrote:
->>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.
->>
->
->I agree with your points in general. Note that the Hardening draft covers
->most of this in the context of requiring stable practice and good
->operational support to be a pTLA. My worry is not in reducing routing table
->entries at this stage of the 6bone, rather encouraging a discipline on the
->6bone of good policy and good practice. 
->
->If we agree in prinicpal on the draft, and each pTLA implements it in
->general, with the goal of a production quality network, we will start to
->identify (and force changes on) the unreliable pTLAs.
->
->I believe that a quality production backbone environment is what we are
->after now, with most of the testing occurring at sites. 
->
->We have had little or no comment on Rob's Hardening draft to date, so I
->would encourage everyone to read it, make comments and improvements to it
->(to the list please).
->
->	<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-harden-00.txt>
->
->
->Bob
->
->
->