...

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-