Re: Vote NO on R-L-G IP Address Allocation proposal

Tony Hain <ALH@eagle.es.net> Tue, 27 October 1992 03:06 UTC

Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa25135; 26 Oct 92 22:06 EST
Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa15535; 26 Oct 92 22:06 EST
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa25127; 26 Oct 92 22:06 EST
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa25103; 26 Oct 92 22:05 EST
Received: from eagle.nersc.gov by NRI.Reston.VA.US id aa15476; 26 Oct 92 22:05 EST
Date: Mon, 26 Oct 1992 19:05:04 -0800
Sender: ietf-request@IETF.NRI.Reston.VA.US
From: Tony Hain <ALH@eagle.es.net>
Message-Id: <921026190504.636@EAGLE.ES.NET>
Subject: Re: Vote NO on R-L-G IP Address Allocation proposal
To: ietf@NRI.Reston.VA.US
X-Vmsmail-To: smtp%"ietf@nri.reston.va.us"

Peter and Ross,

This is an inapproptiate thread for a detailed discussion of a GIX, but a
concise definition is:

A Global Internetwork eXchange point, installed as a common level 2 subnetwork
where peer global networks may choose to exchange routing and traffic. 

Not overly different from your logical definition, but yours missed the 
practical points of a real operational network. There are no transit level 2 
networks defined and intervention of a transit level 3 precludes a peer 
relationship. Just the operational support for maintaining 200 potentially 
different border routers is staggering. Without taking a position here on BGP-4 
or IDRP, consider that the IGP in the non-border routers would have to deal with 
a potential 200 equal cost paths to external networks. Even if your router only 
kept track of the first 3 you have just tripled the size of the routing tables 
in the intra-domain routers.

My real concern was Peter's "loose application" of the term GIX which has a
specific meaning. You can keep NAP's undefined if you choose but don't
confuse them with a GIX.

To be honest I can't find an R-L-G paper. I see an R-L ID of 10/24 and a -G 
as RFC1366 of 10/92. I have seen a note that an R-L-G paper takes the R-L ID 
and appends a the apparently similar but substantially different -G RFC.  The 
prior talks about provider based allocations, while the latter talks about 
macro-geographic regional registries. What did I miss?

For the three options, if the only geographic reference is at the macro level 
I have no problem. If we carry the geographic addressing too far the number of 
exceptions will override any gain that was expected, and be a operational
nightmare (not unlike where we are now, just a different set of expectations).
I have been against any plan that makes change expensive or difficult, so 
provider based allocations has been low on my list. That leaves massive 
resources, which is difficult when the router vendors don't seem to catch on 
that there is a real problem here and we need a router designed to deal with it. 

We have no good short term options. As I have said before, the IP internet is
dying, it just doesn't know it yet. It will soon go the way of the research
Decnets which outgrew the address space. RFC 1366 is an attempt to tide us
over until a new approach is here, and it appears to be our best hope.


Tony