Home page logo
/

nanog logo nanog mailing list archives

Re: Request for Comments on a topological address block for N. Calif.
From: Tony Li <tli () cisco com>
Date: Sun, 24 Sep 1995 02:27:10 -0700


   I was assuming that for the most part, the end users of these addresses
   are going to be connecting via a larger transit provider, not directly
   to the interconnects.  

Well, in that case, the user should CLEARLY get a prefix from the
service provider.

   In any case, all routers in the area we draw the
   abstraction around will have to know where everyone else is... 
   Presumably, if mountainview.net is connected to sprint via a router
   at fix-w, then the sprint presence at mae-w and the NAP will announce
   that next-hop for mountainview.net is via them.  Incoming packets that
   hit the NAP will then go via sprint for the last hop.

This is exactly the free transit that we've been describing.  And
you'll note that you have no aggregation as Sprint now has a longer
prefix running free internally.

   Another alternative, if the big backbones around here object to
   that complexity, is to put a smaller version of this at each of the
   local interconnects (a /9 at the NAP, a /9 at MAE-W, ...) rather than
   draw the boundary around all the interconnects inclusively.

This was Ran's proposal.  While this works, you have to understand
what it doesn't do: it doesn't eliminate the need for renumbering.
What happens when you flip from one interconnect to another?

   I am not trying to make this thing work before the idea is really 
   cooked well enough, but to really make a serious dent in announcements
   then we need to look at constructs like this, if not identical to this,
   becoming more standard.  Right now, larger ISPs aren't getting large
   blocks, and they are allocating things in non-contiguous non-growable
   blocks, neither of which is good.  Nothing is being done to organize
   topological assignments at all, which is seriously not good.

Well, I agree that more coordination is a good thing.  This is the
place to do it.  But arguing about address allocation strategies again
isn't useful.  We should be at the point of fine tuning them.

   I see this as a potential strong first step towards demonstrating
   what we can do by topologically assigning things.  I haven't seen
   serious proposals for better topologically significant assignments.
   We have to start somewhere.

Wow.  What do you think the previous flame-fest was about?

Tony



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]