routing policy questions

[Robert Rockell]

stricly speaking, it is routing table size. On big backbones, when you allow
a more specific to be announced by one of your customers (that is using youR
address space) you not only have to now listen to that announcement from the
other provider that YOU peer with, but you now have to de-aggregate your own
outbound announcements to the rest of the world, which, for instance, if
everyone was multi-homed, that woudl triple your table size (aggregate,
other provider's announcements, and your own deaggreagate) for every
multi-homed customer. In v4, this is already a problem for backbones that
are not optimized to handle >65k routes, and we know that routing table size
can only get bigger.

If everyone would dual-assign their interaces of all machines, then the
routing table size tops out at 15 bits of size, as in any given backbone,
one only needs to hear all the /24 of other TLA's, and then their own
internal /48's that they have delegated. Without doing this, we can see that
routing table sizes grow beyond a manageable amount quickly. This is why I
was asking. 

When a fully implementable solution for v6 occurs, the assignment of address
space should become a lot easier, making this solution more feasible to
network administrators, as ipv6 address assignment will be done
automatically, through the solicited node request stuff.

What had spurred this question on was that I was seeing more specific routes
to a destination from a provider who is not even directly connectected to that
node, than from the network provider who is directly connected. This leads
to bad routing. The only solutions are:

1. stop that and filter on the /24 from other tla's, or
2. allow the /48's and fully de-aggregate your announcements.

-as stated above, #2 is not feasilbe based on potential routing table size.
This is not a problem now, but will quickly become one if this sort of
routing table is allowed to go to production. Just wondering if anyone
actually is doing the nice-guy thing of dually assigning when multi-homed.


Thanks
Rob Rockell
Sprintlink Internet Service Center
Operations Engineering
703-689-6322
1-800-724-3329, PIN 385-8833

On Mon, 7 Sep 1998, Rafal Maszkowski wrote:

->On Mon, Sep 07, 1998 at 08:28:35AM +0100, Buclin, Bertrand wrote:
->> > Should backbone nodes be filtering out anything beyond a /24 
->> > that is not from their ptla? 
->> As Bob Fink pointed out, first of all backbone nodes should only
->> be announcing a /24 for their own pTLA. If everyone does this, then
->> we have already reduced the problem quite a bit. You can receive
->> more specific routes from NLAs as well. In that case, you can easily
->> convince your NLA site to fix the list of prefix they advertise.
->
->Let us imagine a pNLA site with two tunnels to pTLAs. When the main link (main
->in a sense that most machines have IP numbers from this site) fails there is no
->way to reach this pNLA site from anywhere else except second pTLA networks (if
->the agreement provides). The solutions could be:
->- allow to send /32 between pTLAs
->- become a pTLA
->- have a tunnel to every pTLA
->- have double (triple, quadruple, ...) IP numbers (?)
->are there any better ideas?
->
->What is the reason of not propagating > /24 prefixes and how to setup backup
->links not being pTLA?
->
->R.
->