Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Policy Statement on Address Space Allocations

  • From: Noel Chiappa
  • Date: Wed Jan 31 17:38:37 1996

    From: Curtis Villamizar <curtis@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.
	
	Noel




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.