NUMBERING REALLY BIG NETW

[Jeff Binkley]

HC>Perhaps stepping back a bit, and looking at other context, helps. I
HC>will look at two other contexts  in this note, and hope they add
HC>perspective.

HC>I like to ask people, "what's the biggest network in the worlds?"
HC>Many people answer "the Internet."  "The US military" is the most
HC>common alternative answer.

HC>None of these are even close.  It's the international telephone
HC>network (you know, I never looked at it before, but that is a great
HC>name for a conspiracy).  Also important to this discussion is a
HC>"sub-conspiracy" called the North American Numbering Plan.

HC>Look at a telephone number, expanded to include all long-distance and
HC>international prefixes.  It will begin with a national code such as
HC>44 for the UK.  Subordinate to that are city codes in the UK, and
HC>exchange and line numbers in that city.

HC>North American numbers have a 1 country code, and the familiar area
HC>code/exchange/line structure below that.

HC>Telephone routing (switching) operates at the broad levels of
HC>international/major national (continental)/local.  International
HC>carriers interconnect countries; Interexchange Carriers (IXC)
HC>interconnect local areas, and local providers interconnect exchanges
HC>different technical requirements and lines.  There are at each of
HC>different technical requirements these levels, much as there are for
HC>a small ISP that needs to support very good end user dialup, and a
HC>national provider for whom 155 MBPS links (and certainly routers!)
HC>are not fast enough.

HC>Especially due to the advent of new technologies requiring unique
HC>telephone numbers, there has been an extreme demand, especially in
HC>large metropolitan areas, on the telephone number space.  This has
HC>led to certain area codes (e.g., 212, which once covered Manhattan)
HC>to fill up.  There may be space left in Area Code 702 in the deserts
HC>of Nevada, but that isn't usable inside Area Code 212.  Area code 212
HC>has a fixed limit dictated by the 999-9999 phone number structure.

HC>So, there is a practical issue that certain area codes are exhausted.
HC>Telephone  renumbering is a nasty issue for several reasons.

HC>First, if my area code changes, I have to change all my letterheads,
HC>etc.

HC>Second, anyone who has stored my number will have to change it,
HC>whether or not their number has changed or not.

HC>Third, there are several technical ways to introduce new area codes.
HC>The usual way is to split geographic areas, so half the people in
HC>them are affected.  A newer model is "overlay," where additional area
HC>codes are applied to a single geographic area.  The latter model
HC>requires 10-digit dialing for every number inside the local area, but
HC>doesn't force people to change their numbers.  Advantages and
HC>disadvantages to both.

HC>How does this relate to ARIN? There has to be a central registry to
HC>assign area codes.  There is a usually-hidden list of provider codes
HC>that also needs to be administered.

HC>When one gets a telephone number in a geographic area, the number
HC>assignment is given to the end user by their serving telephone
HC>company. That telephone company aggregates the subscriber into an
HC>exchange, and then an area code.

HC>If one moves their business to another area code, there is rarely a
HC>presumption that the phone number is portable.  It was allocated to
HC>the aggregating provider.  The telephone switching system has a
HC>finite address space, there is an extremely large capital investment
HC>designed to deal with this, and the system was not designed for
HC>portable addressing.

HC>IP wasn't really designed with either portable or nonportable numbers
HC>in mind.  RFC760 started with an 8-bit prefix that soon proved
HC>unscalable, and changes were made.  But  that 8-bit prefix reflected
HC>IP was introduced for small research functions where lots of
HC>flexibility was practical, but has evolved into an environment much
HC>more constrained to maintain operational quality.

HC>An issue that concerns many people on the ARIN list is being "locked
HC>in" to a single upstream provider, assuming the general case is
HC>provider-based allocation.  One concern here is the disincentive for
HC>people to go with small providers, because they may need to renumber
HC>as the small provider grows.

HC>Yes.  This is a true statement. To say it is not -- to say I have
HC>provider independent phone number space -- is saying I get to move
HC>from (703)998-5819 in Virginia to Silicon Valley, and can reasonably
HC>expect to get (408)998-5819, or even keep (703)998-5819 with no call
HC>forwarding expense.

HC>There are two ways to look at this.  One is that renumbering is
HC>anticompetitive and must not happen.  The other says there are
HC>technical reasons to renumber, and probably good ones.  Let's focus
HC>on making renumbering less painful, because it will be a fact of
HC>life.  Let's also realize there are significant real world examples
HC>where even large end users might face renumbering of their Internet
HC>interfaces, but would have to renumber a very small portion of their
HC>users.

HC>Making renumbering easier is the focus of the IETF Procedures for
HC>Internet/Enterprise Renumbering (PIER) Working Group.  It has a web
HC>http://page at www.isi.edu/div7/pier/.  Minutes and such are at
HC>http://ds.internic.net/ietf/pier/.

HC>PIER has produced several RFCs, and more are in the works.  There is
HC>also a collection of renumbering case studies, which I _think_ the
HC>web page points to.  With all due humility (yeah, right), two RFCs
HC>that might be of use to ARIN are
HC>http://ds.internic.net/rfc/rfc2071.txt and
HC>http://ds.internic.net/rfc/rfc2072.txt.  The first is an overview of
HC>the renumbering problem by Paul Ferguson and myself, the second is an
HC>operational-planning-oriented document I wrote called the Router
HC>Renumbering Guide.

Howard,

Having worked for the phone company many years, I am very aware of your
comments.  There are a couple of other things to keep in mind when
comparing this to the ARIN proposal.  First, Bellcore was the governing
body which originally setup the North American Numbering plan, which at
that time was solely funded by AT&T, which was a monopoly.  The plan,
while still holding true today, had similar problems with allocations
and limitations.  Those were/are always handled as an enginering issue
and not a monetary one.  800 service brought this to a head as they idea
of portable 800 service and the switching of long distance carriers, for
outbound service, came into issue.  These were some of the main driving
factors for the CCS7 switching system and national 800 database.

The big difference here is that in the telephone world, the current
holders of the keys are the access providers (i.e. RBOCs) and not the
long distance companies.  This is backwards to how the Internet is
currently heading.  As smaller internets develop and local/regional
backbbones grow, I can see the Internet heading the same route.  Then
the whole issue and idea of registries takes on a different focus.

On conclusion I am not sure the idea of a pay-for-admission body such as
ARIN will solve the engineering issues that route consolidation
apparently needs.  I am more concerned that certain groups may decide to
join ARIN so they can leverage their business agendas. Of course because
we don't have and probably don't want something akin to the FCC, there
does need to be some paletable solution.

Jeff Binkley
ASA Network Computing

CMPQwk 1.42 9999