[c-nsp] IS-IS default route quandary

[Justin Shore]

I'm trying to figure out a default route issue that stems from our 
original IS-IS deployment.  The entire IS-IS deployment is a flat L2 design.

      A    B
      |\  /|
      | \/ |
      | /\ |
      |/  \|
      C    D

A & B are border routers and C & D are our 7600 core.  Each border is 
dual-homed to each core router.  The access edge routers (DSL, cable, 
metroE, dialup, etc) are dual-homed to the core routers as well.  Full 
BGP tables are extended to core (A-D are in an iBGP mesh).  The access 
edge can't handle full routes.  Customer routes are still in IS-IS but 
I'm slowly moving them to iBGP.  To dynamically learn a default route on 
the access edge via IS-IS I have to originate it somewhere upstream. 
The borders currently originate the default route in IS-IS and advertise 
it to the core which propagates that on to the access edge.

On each border router we also have a static default route pointed to the 
physical interface of the upstream peers (which if memory serves me 
correctly that's a bad idea because it causes an ARP to be sent for 
every flow that requires that specific route).  This is a hold-over from 
my predecessor and hasn't been scrutinized until now.  When I pull the 
static default from either A or B it relearns the default from the core 
routers, C & D.  Now when I do this it still has routes pointing to all 
the advertised prefixes on the Internet thanks to the full tables so I 
don't think I'll have any reachability issues.  Or will I?  My main 
concerns are that this will cause a routing loop between the borders and 
core for any routes that aren't in the borders' RIB.  This would mainly 
be BOGONs and other non-routable space that we use internally (so it may 
not be a real problem).  In theory I shouldn't ever have to rely on a 
default route to my upstreams thanks to my full tables.  I'm also 
concerned with how this may affect my uRPF and RTBH setup.  Would this 
catchall route nullify the effect of a iBGP-learned null-route from my 
RTBH setup?

I would prefer my borders to not have a default route vs a default 
pointing back to my core.  Is there a way to not accept the default via 
IS-IS?  L2 IS-IS speakers will propagate all L2 routes to all L2 
neighbors.  We could not get a L1 and L1/2 design to work early on in 
our testing so we chose the flat L2 approach instead.  Is there 
something else that I'm missing here?  Down the road I'll have to 
directly connect the borders together due to our upcoming SCE deployment 
(longer story).

Thanks
  Justin