Milo, You may be overestimating the problem. This is only an issue for regionals who are using default. If you are routing via explicit announcements from the backbone, it is a simple matter for us to filter out the AS 1957 announcement to exclude this traffic. Or alternatively you can do this in your peer router. For regionals using default, it isn't possible to prevent traffic from being sent from the regional to the CIX. One might think that it would be possible to prevent traffic in the other direction by filtering the announcement of that regional's networks by the backbone to the CIX. But this is also not possible since the CIX member networks are pointing default at the NSFNET backbone. So routing will be asymmetric but it will work. I can make available a postscript picture of the whole routing situation, if that would help. As far as whether this process has been open or not, first I should say that this is not really a Merit/NSFNET issue. It is an agreement between ANS (our subcontractor) and the CIX. As NSFNET service provider we are trying to facilitate this interconnection for the benefit of regionals. We were involved in the discussions of routing design (in fact Jessica Yu provided quite a lot of consulting with this) but the requirements were laid out by ANS and CIX. BARRnet and NEARnet were involved, as they are both ANS and CIX members and will make use of this interconnection. In any case we haven't made the change yet and I am certainly open to constructive (or even other types of) suggestions. We are currently working on verifying the integrity of the list of nets within AS 1957 and finalizing the confirmations with the current AS's for the database. The actual configuration date is at least a week or two away. Let me know if this helps or not. Mark
From: "Milo S. Medin" (NASA ARC NSI Office) <medin@nsipo.nasa.gov> To: mak@merit.edu CC: bjp@sura.net, regional-techs@merit.edu
Mark, the issue as I see it is that the current plan for implementing CIX connectivity is a change from the previous policy, and that you are now shifting responsibility for ensuring this filtering from your routers to the regionals, which for the regional, may involve significant administrative load, and which is the organization best capable of dealing with that administrative load.
Further, there is also the issue that this plan does not appear to have been developed in a cooperative fashion with the regionals and other peers network
s
as a whole, as past shifts of functionality and responsibility between the backbone and regionals were done.
I think there is not uniform consensus that the approach described is the best way of accomplishing the end goal, which also hasn't been described in a very explicit way, and is complicated by goals that NSF has and potentially other goals that ANS itself has. I'm not saying there is a confl ict here, just that the precise goals and objectives do not appear to be well understood by all parties involved. This of course leads to confusion, which in turn will impede progress on any approach selected. It's hard to judge when you've got a good design if you don't understand what the requirements for the design are!
Please feel free to correct me if I'm off base here. This is just my perception at this point, and I'm really not trying to throw stones, just trying to make sure evryone is working together on getting the job done right.
Thanks, Milo