Are the Route Servers Viable Solutions That Are Being Held Hostage?

Fri Dec 22 02:16:04 UTC 1995

In message <Pine.SUN.3.91.951220005149.13779L-100000 at tigger.jvnc.net>, Gordon C
ook writes:

    On Sunday the 17th of December Sean Doran stated pretty clearly why 
    Sprint wasn't using the Routing Arbiter database.  I am very surprised 
    that neither Bill Manning or Elise Gerich or anyone else involved with 
    the project has so far come back and said no...Sean....your 
    interpretation was wrong.  Here is what we did.  And we did this 
    because........  Does the lack of response from the Routing arbiter to 
    Sean mean that it has no problems with Sean's description of what it did 
    and why it did it?

I offer the theory that the lack of response was due primarily to
people who have real work to do.

    To refresh folk's minds, here is what Sean said:

    The principal problem is that the RSes and the whole IRR
    are only as good as the databases are, and the bulk of the
    RADB was populated from the wrong source.  Rather than
    doing what I would consider the correct thing -- that is,
    watching peerings between the RSes and the providers
    participating in the various RS tests and tracking down
    all the information from the IRR based on what was seen
    there, verifying routing policies with end sites -- they
    started with the PRDB and hoped that fate would cause the
    RADB to become more correct.

The information taken from the PRDB was the prefix itself, contact
information, and the AS690 advisory fields.  The origin AS was not in
the PRDB.  This was instead populated by asking people to register the
correct origin AS or by observed AS paths where there was no response.
The origin AS fields are largely incorrect due to truncated AS paths
which results from using the exact technique that Sean prescribes,
looking at the routing table for a source of information.

The AS690 advisories were also largely incorrect due to the topology
changes that occurred during NSFNET transition not being reflected.
This was also largely due to the AS690 advisory method of
configuration becoming increasingly unwieldy as the network has grown.

The AS690 advisories are now gone.  ANS policy is now entirely
expressed in the AS690 aut-num (the authoritative aut-num is in the
database named "anstest" on configs.ans.net).  The move to clean up
ANS policy (greatly reducing inconsistencies and simplifying the
policy) is underway and making good progress (for example, in the last
7 days the size of the AS690 aut-num object was reduced by about 4,000
lines due to simplifications of policy and increased use of BGP4 MED).

    To be brief and blunt, the RA team started with
    information explicitly designed to PREVENT connectivity
    between "bad" (evil, greedy, commercial) networks and
    "good" networks which would be AUP compliant.  I'd think
    common sense would indicate doing some extra (and well
    paid) work to instead start off with something approaching
    a model of the reality of interconnectivity.

This is pure flamage.  The only thing the AUP reflected in the RADB
was whether the comm-list for a route contained the community
COMM_NSFNET was set.  Since no one uses that community for anything
(that I'm, aware of), it has no effect.  A lot of the route objects
were picked up simply from route dumps at the CIX, when ANS policy was
to automatically register in the PRDB any route found at the CIX as a
commercial only route with CIX connectivity only.  That was hardly
designed to prevent connectivity.

    Moreover, another disappointment is that one could easily
    assert that a strong reason for using the PRDB as the
    source of information from day #1 was that MERIT was
    already spending its resources maintaining that database
    and toolset in a deal with ANS to keep ANS's network
    routing working much the same way during the many months
    while they figured out how to move on from the end of the
    NSFNET backbone service.

ANS did and still does want to maintain the most reliable routing
possible toward anyone willing to register accurate information in the
IRR.  The only choices for starting the database was to start empty or
start with the best information available at the time.

    In short, I think the chief failing of the RADB is not the
    toolset, the concept, or the long-term plan, all of which
    make some to alot of sense.  Instead, what seems to have
    killed it dead is that the RA was too busy to commit the
    *serious* effort it would have taken to populate the RADB
    with information from reality in the first place.

I don't see how Sean expects the RA to populate contact information,
origin AS, maintainance authorization and notification fields, AS
connectivity, based on seeing an BGP route in a routing table.  I also
don't think Sean is entirely representing Sprint, since others at
Sprint are populating information so their customers get connectivity.

The RA is working on a lot of analysis tools.  Among them are
verification tools to determine whether what is observed in BGP
updates is feasible based on what is present in the IRR.  The attempt
is being made to make entering information as easy as possible for
those who do not wish to fully participate.  When a new AS appears, an
aut-num object should be entered so people have a basis for
determining backup paths in addition to a primary path.  If new
prefixes appear, all that needs to be registered to get routing right
is the prefix and origin AS.  Correct contact information is a nice
idea too, be we can route without it if we have to.

There are many parties contributing toward improving the accuracy of
the IRR, whether by developing better tools or by adding information
or correcting information for which they are authoritative.  The tools
right now are primarily coming out of the RA.

There are also those who are not contributing to improving the
accuracy of the IRR or even worse persistantly whining about it or
flaming others who are.  Those people doing real work are trying hard
to just ignore those who are whining and flaming.

    ********************************************************************
    Gordon Cook, Editor & Publisher    Subscriptions: Individ-ascii  $85
    The COOK Report on Internet                Individ. hard copy   $150
    431 Greenway Ave, Ewing, NJ 08618          Small Corp & Gov't   $200
    (609) 882-2572                             Corporate            $350
    Internet: cook at cookreport.com              Corporate Site Lic.  $650
    Web:  http://pobox.com/cook/    Newly expanded COOK Report Web Pages 
    ********************************************************************

Curtis