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