ANS to CIX Interconnection

Fri Oct 2 07:49:03 UTC 1992

Eric, my note which the mailer at merit bombed on yesterday in fact pointed
out exactly what you say about the shortcomings of the approach of not 
installing routes in the ENSS's.  In the particular case of BARRNET and 
NEARNet, I believe all of the peers adjacent to those ENSS's would 
want the CIX routes and have signed the CO+RE agreement.  But you are
right, this approach has it's limits.

The real question here is that this change shifts administrative load and
responsibility from the "core backbone" to regional network managers.  For
a variety of reasons, NSI doesn't have a default route at our border
routers on the FIXen.  However, this is a rare configuration in the
network, and in fact, is relatively new in the sort of history of the Internet.
Back in the old days, everyone connected to the ARPANET backbone, and hosts
picked up redirects from the "Core" gateways.  Then came EGP, and again,
routers attached to the ARPANET were used as default by folks behind them.

This same model was used with the Fuzzball based system,  albeit without a
"cloud" technology in the middle.  Later, the T1 NSFNET perpetuated this
and the T3 system has continued to perpetuate it.  "Generations" of network
managers were raised with this sort of thinking, and configuration 
procedures, and how people implemented workarounds took advantage of 
this structure.  It's more than just the configuration of border gateways,
it's the way people think.  I don't consider default to be a kludge at
all.  It's highly compact route summarization!  Sort of CIDR in the
extreme.

Now, a change is being proposed to this model.  Note that in the previous
examples, the "Core" always carried total routing information for the
general purpose system.   Nets which didn't want total internet access wern't
advertised to the core.  Being THE general purpose transit AS has always 
meant being the target of default routing.  It's sort of the structure 
that has evolved over the years.  It may well be the case that it's usefulness
is nearing an end, however, this is a major change in the way people do business,
and build systems that attach to the Internet.  If it's to be pulled off
with a minimum of pain, lots of things need to happen.  Some people need to
redo the way their AS's do routing (a bit at least).  Routers at the borders
might need upgrading to support the number of routes to be transferred, processed
and stored.  EGP frag. reassembly buffers may need to be increased, and BGP
deployment accelerated.  Backup routing configurations need to be re-examined.  
Administrative procedures may have to be changed, and staff utilization
readjusted accordingly.  It's probably unlikely that any one organization
would have to deal with ALL of the things I just mentioned, but I'd wager
that many would have to deal with at least a few of them.  

My point is that this change is potentially a big deal, and needs to be 
addressed for what it is, a system change in the way routing to NSFNet is done.
There will be costs associated with this approach, costs which may be less
with a different approach that might accomplish the desired objectives.  But
since this change (no longer having a default route to an ENSS) affects
so many organizations, it seems to be not just an ANS engineering issue 
internal to the way their backbone operates.  Granted, folks like Alternet
might not have to deal with the same sort of problems, but being the 
provider of the NSFNet backbone carries with it special requirements that
others don't have.  

I don't mean to sound critical here of the ANS or MERIT folks at all.  Far
from that, I think they are really trying to do the right thing.  However,
this is an approach that affects LOTS of organizations.  It's a change in 
"service interface".  I think that by having the backbone work together with
the regionals and other networks, modifications or alternate approaches which
might not have the same impact might be developed.  In fact, this sort of 
cooperative effort may well expand the envelope of design beyond what MERIT or
ANS felt they were working with. 

Certainly, if there was no cost to the regionals in getting access to CIX
networks via the ANS network, then you might be able to finesse the issue
by letting the folks who used default run that way, and those like us who
for policy reasons couldn't, would have to bite the bullet and not use default
anymore (if they were using default in the first place).  But then the
question of why this interconnect was being put in place in the first 
place has to be dealt with, and that's still unclear at this point in 
time, at least to me.  In line with the NASA Total Quality Management
philosophy, I think it's important that all the participants understand
what the end goals and objectives are, and that information be used
to determine the quality of a given design or approach.  It might be possible
that I'm just being obtuse about this (I'm known to be obtuse about a wide
range of subjects), but I've gotten several notes from people who seem 
to be just as confused as I am.   

Anyways, if such a change is going to be made, it ought to be engineered 
with all the parties involved, and everyone understanding what the impact
is going to be.  If nothing else, I think this recent dialogue has helped 
to do that.  After all, the only way the Internet system works at all is by
tight cooperation with the backbones, mid-levels and campuses.  That kind 
of cooperation is going to be key in the evolution of how various 
interconnections occur.  We're all in this together.

						Thanks,
						   Milo