More Specifics of Classful Nets

Steve E. Powell sep at ans.net
Mon Dec 6 17:32:47 UTC 1999


Greetings.  I was following the Verio thread and just wanted to throw
out another idea.  It is not well thought out, but that is what mail
groups are for.  It appears that some of the reasons for blocking on
prefix length are to encourage aggregation/summarization of routes
and to protect against route explosion disaster due to human error
or insane code.  However, there are organizations that have been
allocated blocks that are required to be carried as components.
One reason is they are duel homed and another is the orgainzation's
internet access spans multiple ISP's  Why not have bgp do the work
for us?

What if the operator had the capability to accept routes based on
the ratio of good prefixes to bad prefixes received where a bad
prefix is defined as a more specific of a classful network or a
classful prefix in swamp space.  The idea would be that if ISP A was
sensitive to prefix length, ISP B that announces routes to A could
only expect ISP A to accept N bad routes providing M good routes
are also advertised.  A good route could be defined as a range of
a certain prefix length that does adequate aggregation.  Using some
numbers, ISP B announces 10000 routes to ISP A.  2000 routes are of
an adequate prefix length for ISP A to define as good.  ISP A will
allow one bad route for every 100 good routes that are advertised.
ISP B wishes to announce 25 bad routes to ISP A.  Only 20 routes are
accepted by ISP A.  The last 5 routes are not accepted until ISP B
can convert some of the 8000 neutral routes into 500 good routes.
Alternatively some good routes might be weighted as better, allowing
for more announcements of bad routes.  For example an ISP that
could announce a 14 bit prefix out of swamp space would be rewarded
more then one that announced a 16 bit prefix out of swamp space.
If a customer of ISP B observes that their bad route is no longer
routable over ISP A because B is announcing more bad routes, it
will ISP B's responsibility to behave better by either aggregting
better or removing the new bad components.  Else ISP B will have
to deal with the wrath of their customer.

These ratios could be part of peering contracts.  Each side
would understand how many bad routes the neighbor will accept.
It could also be stipulated contractually that a session would
be torn down if an excessive number of bad routes were observed.
I see no reason why excessive components cannot be treated the same
way as a bad attribute.  In this case I am defining excessive as
hearing thousands of extra components, not a handful over the quota.
This could be an alternative to having to carry every discrete
route in a filter to protect oneself or filter on prefix length.
Obviously, there are a lot of implementation/practical issues that
I have not thought of.

stevep




More information about the NANOG mailing list