[j-nsp] full table?

[Pavel Lunin]

> Is it always necessary to take in a full table?  Why or why not?  In light
> of the Saudi Telekom fiasco I'm curious what others thing.  This question is
> understandably subjective.  We have datacenters with no more than three
> upstreams.  We would obviously have to have a few copies of the table for
> customers that want to receive it from us, but I'm curious if it is still
> necessary to have a full table advertised from every peering.  Several ISP's
> will allow you to filter everything longer than say /20 and then receive a
> default.  Just curious what others think and if anyone is doing this.

1. If you have downstream ASes, than full table is [most probably] 
needed to be not just received but also used for forwarding (this is by 
default, but you can alter, see below). Otherwise loops/blackholes are 
possible in specific scenarios (split customer's AS, etc). Workarounds 
exist for this, but they are rather too complicated to maintain and make 
everyone in NOC to remember how it works. Some folks (especially DCs) 
don't care and just send full table to customers, not having it in data 
plane. For DCs with just few customers with their own ASes, this 
approach works well almost always (until something breaks). When issues 
arise, they troubleshot it and rewrite policies to accept additional 
routes. Not very good, but I saw this many times.

2. You must remember (people forget these basics surprisingly often), 
that full table, you receive from upstreams or IX-peer, is used to 
_send_ traffic. So when you think it's useful to have full table to 
analyze or somehow intellectually influence traffic balancing across 
uplinks, you must remember that it only relates to traffic going _out_ 
your AS. Every couple of weeks I talk to someone who believes, he needs 
to receive full table, since he wants to "balance traffic". When I ask 
them, how much traffic they send out, it usually turns out to be not 
more than 10% of a single link capacity, and they don't experience any 
problem with it at all. And yes, most of them need to balance incoming 
traffic, but full table has nothing to do with this.

4. Most platform allow using two or more defaults with ECMP enabled. 
Real routers (like MX series) also allow using bandwidth-communities to 
make LB really asymmetrical (30% through ISP1, 70% through ISP2). If you 
need it, say, in case of different uplink capacities (10G and 1G). L3 
switches (e.g. EX series) can't do this because of their much simpler 
(and cheaper) PFEs.

5. It does not depend on ISP, if you want to strip things out the full 
table (this is _your_ import policies), you can write any policy you 
wish, but all these tricks with not receiving "anything longer than" 
eliminates most of the full table advantages. If you want partial table, 
you better filter routes somehow more consciously. E. g. 
international/domestic, routes to your/customers' remote locations, 
routes to ASes, to which you send most of your traffic, etc. Of course, 
you customers won't be much happy, if you send them a partial instead of 
full table. So if you filter something out, you most probably need to 
play games (not without cheating) with forwarding along partial but 
sending full table to customers. See rule number 1: first, be afraid of 
loops and blackholes, second, this is an art and not easy to maintain, 
especially when different NOC shifts have to troubleshoot and resolve 
issues quickly.

6. If, after checking rules 1–5, you are still not sure if you need full 
table — you definitely don't.

Having this said, I'd say, full table is needed because of the 
downstream ASes. Playing the games described above does not worth it.