Policy Statement on Address Space Allocations
jnc at ginger.lcs.mit.edu
Wed Jan 31 21:03:52 UTC 1996
From: Curtis Villamizar <curtis at ans.net>
> We can also limit the amount of routing overhead by providing configured
> AAB boundaries for a given multihomed site which enclose a path between
> the primary and secondary providers. Since this will in some cases
> require ... automated tools we don't have yet, don't hold you breath for
> that one either.
You may not have to wait as long as you think. ... The idea is to provide
a means to specify the aggregation boundary within the IRR and provide the
tools to transform that specification into router configurations.
Oh, I should also mention that Tony Li did have an idea for how to do
something like the above (providing a path between primary and secondary)
automatically; it involves forwarding a more specific route toward the source
of a more generic route. This is worth investigating, I think.
One issue with that approach is how good the routes are to the destination if
the link to the primary goes down. A lot of traffic might wind up taking two
sides of a triangle, but maybe that's OK for a fallback. The configured AAB
probably provides better routing after a failure has happened, at higher
routing overhead of course.
Also, another way to think of these things are as "partition repair"
mechanisms. Some routing protocols which support areas also support automatic
partition repair mechanisms; IS-IS does this with a tunnel. Maybe we should
look into the work that has been done in that area, too.
This code will enable ANS to do much better aggregation that we now do
regardless as to whether other providers buy into the idea. To accomplish
the type of multiprovider cooperation you refer to above, it is a matter of
getting someone else doing the same thing, or something similar enough
that we have someone to cooperate with.
I think that eventually we're probably going to have to look into abstraction
control mechanisms that operate on scales larger than a single provider; not
clear how urgently that will happen.
It's true that we are having to sit fairly hard on the 32-bit space to fit
everyone into it, but now that multi-level CIDR is being deployed, that is not
as big an issue. The big issues that I see coming up now are things like:
- How do we set AAB's and similar configured items; the current hand
configuration of things like this just won't keep working.
- The need for continuing to add levels of abstraction (we're currently up to
about 5 - carrier, ISP, customer, subnet, host) but need to keep going to
keep the routing table growth supportable as the growth in net size continues
to outpace technology growth. In other words, addresses will likely have to
be more organized at higher and higher levels (since the lower ones are
already pretty logically assigned), which is going to be very painful indeed.
More information about the NANOG