Route table growth and hardware limits...talk to the filter

Mon Sep 10 06:55:16 UTC 2007

>> how about a filter between in-rib and what you actually crank 
>> through the churning clothes washer?  pass on the in-rib, calc on 
>> the phyltered data.  so when shorter prefix is withdrawn, you can 
>> look for next best candidate.
> Possible, but decidedly non-trivial.  Recall that if you're going to
> phylter before the RIB, then you'll have to reflect that in your BGP
> advertisements too.  Any route caught in the phylter must be 
> withdrawn if it has been advertised.

i am not happy with just announce from input, but note that it would
remove this problem.  it would also throw the best path baby out with
the bathwater.  i don't think we are ready for that.

>> note that my original proposal/case some years back allowed a 
>> number of flavors of phylter, longer+same-next-hop, 
>> longer+same-as-path, longer+same_origin-as.
> Full time employment for BGP geeks.  ;-) On the flip side, the number
> of variants of expert systems that you're proposing suggests that 
> there be one configurable mechanism. Complexity++;  ;-(

and even more hidden policy, which uncle tim warns us will lead to a wsj
article some day (appended).

but i am slightly more fearful of the cost of routing table growth and
table churn.  slightly.

randy

---

appended is a position statement from wired 2003.

Tim Griffin
----------------------------------------------------------
ROUTING POLICY LANGUAGES MUST BE DESIGNED AND STANDARDIZED
----------------------------------------------------------

The following scenario MUST take place within the next few years: The
Interdomain routing system will enter a state of non-convergence that is
so disruptive as to effectively bring down large portions of the
Internet. The problem will be due to unforeseen global interactions of
locally defined routing policies. Furthermore, no one ISP will have
enough knowledge to identify and debug the problem.  It will take nearly
a week to fix and cost the world economy billions of dollars. The world
press will learn that the internet engineering community had known about
this lurking problem all along....

So, we better have a solution! I'll argue the only way to effectively
solve this problem is to define routing policy languages that are
guaranteed to be globally sane, no matter the what local policies are
defined. Then these languages need to be standardized and BGP speakers
MUST be forced to use them.

This raises many interesting research problems. Is it possible to design
such languages? How can we find the right balance between local policy
expressiveness and global sanity? What exactly do we mean by "autonomy"
of routing policy?  Do we need additional protocols to enforce global
sanity conditions? How can we enforce compliance of policy language usage?

-30-