North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: 206.82.160.0/22

  • From: Michael Dillon
  • Date: Fri Sep 22 12:15:00 1995 
On Fri, 22 Sep 1995, David R Conrad wrote:

> I'm confused.  You were given a /22 by InterNIC which is (presumably)
> provider independent, and which included a statement from InterNIC
> that says that routing is not guaranteed (which should, of course, be
> obvious) and you seem to be claiming they didn't understand about
> route aggregation.  I would assume InterNIC encouraged you to obtain
> your address space from your service provider (Sprint) so your routes
> could be aggregated in your service provider's block.  Are you saying
> that Sprint refused to allocate the space you required?

That last sentence is based on an assumption not a known fact.

> No.  InterNIC is only the ultimate arbitrator of who a particular
> address is delegated to within the blocks that InterNIC has authority.
> This has absolutely nothing to do with routability of those addresses.
> There is no ultimate arbitrator for routability -- it is a cooperative
> effort by all service providers.  Due to routers falling over, some
> service providers are not interested in being as cooperative as they
> once were.
> 
> >I can only
> >strongly discourage the implementation of the prefix filtering for prefixes
> >longer than /18 in 206.* through 239.*
> 
> What is your suggestion to reduce the routing overload?

I think the real problem here is that Kazakhstan should have a block of 
addresses with a short enough prefix to guarantee routing and these 
addresses should have been allocated out of this block.

The obvious solution to this immediate problem is to guarantee routing 
for the long prefix until the event in Kazakhstan is over and then to 
think hard about what to do about similar cases that are not for short 
term events.

After all, this case is precisely the kind of thing Sean wanted to get 
aired in open discussion and it is obvious that any solution to the
"number of routes" problem has to deal with these kinds of issues as well.

Michael Dillon                                    Voice: +1-604-546-8022
Memra Software Inc.                                 Fax: +1-604-542-4130
http://www.memra.com                             E-mail: [email protected]