The CIX and the NSFNET regionals - a dilemma
As some of you are probably aware, BARRNet is in the process of establishing a connection to the CIX. While working out the details of how routing will work between BARRNet member sites and customers/members of other CIX-connected networks, I have run into some difficulty which may indicate a fundamental problem for use of the CIX to interconnect research-oriented networks. In short, I believe that such networks face a serious dilemma if they connect to the CIX: how to provide unrestricted commercial-to-commercial access to the CIX-reachable networks while at the same time providing optimal routing over high-bandwidth NSFNET paths for research-oriented traffic. All, of course, while not creating large amounts of management overhead or strange routing anomalies. I would very much appreciate feedback from this community on the enclosed message, which I originally sent to the CIX tech group. Of particular interest to me is whether this group considers the assymetric routing which would be engineered by my proposed "solution" to this dilemma to be an issue and whether or not the "solution" would adequately address any NSFNET AUP concerns (I use the world "solution" loosely as I am neither proud nor very pleased with the described scheme). Thanks, Vince Fuller/BARRNet --------------- As you are probably aware, BARRNet is in the process of establishing a connection to CIX-WEST in Santa Clara. At this time, pretty much all of the administrative details of doing so have been finalized. While thinking about how routing will work, however, it occurred to me that there are some major technical details which remain unresolved. In particular, how are we to deal with routing between research-oriented networks which should use the T3 NSFNET but which will use the CIX due to the way routing is set up (as I understand it, current CIX members prefer all CIX-advertised routes over those which they may learn via the NSFNET, either by weighting advertisements or simply by only using the NSFNET as a default path). This will be a problem (politically severe immediately, technically eventually) for certain paths, such as for BARRNet sites which wish to access the San Diego Supercomputer center (and I assure you that there are several universities attached to BARRNet which have high bandwidth requirements for this particular case), and will become more severe as the T3 NSFNET becomes fully deployed. To solve this problem, it is necessary to determine whether a given network conversation is affectted by the NSFNET AUP or not. Since conformance to the AUP is based on the content of the conversation, it is not possible for the routing system to do this in an automated way - the best approximation we can make is to divide the world into those networks which are unaffected by the AUP (I'll call them "research" sites) and those which are. Routing via the NSFNET would then be preferred for all traffic which inolves a "research" site and via the CIX for all else. Unfortunately, I don't believe such a routing plan is implementable using current technology, as it requires that routing decisions be based on both traffic source and destination. The best that could be done would be to bias routing such that the each CIX-connected midlevel prefers any NSFNET path it has to "research" sites over the CIX path. This could be done in two ways: 1. Configure each CIX-connected mid-level to suppress advertisement of "research" sites to the CIX, guarenteeing that those networks are only reachable via the NSFNET. 2. At each CIX-connected mid-level, adjust metrics such that advertisements for other mid-levels' "research" networks are preferred via the NSFNET. Either "solution" creates a number of problems: 1. Routing must be coordinated among the CIX-connected mid-level networks to establish which networks are "research". Not a technical problem, but procedurally a pain in the neck. 2. Both are unwieldy in that each CIX-connected midlevel will need to maintain a list of all of "research" sites, either within its own network (solution #1, painful) or from all other CIX-connected midlevels (solution #2, more painful) 3. Both engineer route assymetry into the system. This is ugly and may or may not be acceptable. To expand on point #3, here are examples involving real sites, one "research" (Berkeley) and one "commercial" (InterOP) site in BARRNet and one "research" (ISI) and one "commercial" (Hughes Aircraft) site in CERFNet/Los Nettos (I picked these out of a hat, so to speak; I have no idea how much actual traffic flows among these four). In order to allow the NSFNET path to be used for the "research" sites, both CERFNet and BARRNet will need to hack their routing configurations to prefer the NSFNET path for Berkeley and ISI. This generates symmetric and "appropriate" paths for two of the possible communication pairs: Berkeley<->ISI and InterOP<->Hughes, but codifies assymetry for the mixed "commercial" and "research" pairs. For Interop<->ISI, BARRNet will route to ISI via the NSFNET but CERFNet will route back to InterOP via the CIX. In the Berkeley<->Hughes case, BARRNet will use the CIX to route to Hughes but CERFNet will route back to Berkeley via the NSFNET. Not pretty. There is also another policy problem with the presence of the NSFNET and it's AUP - even if all CIX-connected organizations are configured to prefer routing via the CIX for "commercial" networks, what happens if the path between two "commercial" networks via the CIX fails? If the networks are also advertised via the NSFNET, suddenly what was an unrestricted path between the two is now subject to the NSFNET AUP, without the knowledge of any user. It seems to me that the only way to prevent this is to never advertise to the NSFNET those networks which may wish to transmit any non-AUP traffic. Have these problems been previously addressed by the CIX membership? Are there solutions which I am missing? Does no one else consider these issues to be a problematic? When I explained this to my management, there was very serious concern voiced, in particular over the use of the non-T3 path for AUP-conformant sites (i.e. between BARRNET members and SDSC), since traffic between purely research-oriented sites (such as universities) should use the network which has been expressly provided for it - the T3 NSFNET. Your comments and thoughts on this matter would be greatly appreciated.
I believe that Vince is completely correct. With current routing protocols the NSFNET AUP policy can only be implemented with contorted and sub-optimal topologys and routing configurations. (One could argue that the policys are optimal for securing other goals in a wider arena, but that is not a technical discussion). In a general sense PC routing (that is "politically correct routing") requires switches to know the usage policys of both the source and destination sites. This means that traffic must be routed on the basis of both its destination address and SOURCE address and there needs to be some mechanism of associating the usage policys with remote addresses. Neither part of this can be accurately implemented by current protocols and architectures. Consider the following simpler situation that came up in Pennsylvania a while back: We (PSCnet) are NSF R&E. PREPnet transits PSCnet to reach the NSFnet backbones. Intra PREPnet traffic is NOT subject to the NSF usage rules, and does not distinguish between commercial and non-commercial internal sites. There was a proposal for PREPnet to acquire an additional ANS connection to address two goals: redundant paths for the research users and an external path that was not subject to the NSF rules. It was correctly observed that inbound traffic (from the backbones to the sites) could be PC routed, as long as the remote site/backbone/interchange did the correct thing. However, outbound traffic (sites to backbones) could not be "PC routed". The problem is that all traffic from commercial sites to remote commercial sites MUST leave via the ANS connection, yet all traffic from research sites strongly prefers to leave via the PSCnet connection. Given the topology under consideration this required traffic to flow in opposite directions on the same link to the same destination, depending on the source of the traffic. This can not be done today. period. PSC's position was that if PREPnet accepted comercial interstate traffic from any customers, then PSCnet could not accept any traffic from PREPnet. PREPnet would then be single attached via ANS. Any other position would have put us in violation of our funding. (This predated the NSF/ANS co+re policy, which provides an out.) As I look over the other replys, I see that many have missed a point that I assumed: The problems arise when there is a (complex) midlevel carrying mixed traffic between assorted sites and both flavors of backbones. It is not a problem if the midlevel is "pure" research or commercial. It is less of a problem if both backbones land on the same FDDI dmz. It is clear to me that one of two things is going to happen: The rules will change, and there will be good technical solutions. -or- The rules will not change, and we will have split research and commercial networks with weak interconnects. Organizations that really need to function in both worlds will have two network numbers or two connections.... --MM--
Date: Wed, 05 Feb 92 02:43:57 EST From: mathis@pele.psc.edu It is clear to me that one of two things is going to happen: The rules will change, and there will be good technical solutions. -or- The rules will not change, and we will have split research and commercial networks with weak interconnects. Organizations that really need to function in both worlds will have two network numbers or two connections.... Good assesment. One thing that I have noticed in life, people don't always see their way clear to perform preventative measures (oh, money is too tight, I don't have time, etc.) but they sure scream when the damned thing breaks. Perhaps we ought to start encouraging companies to start requesting more than one network number: one for RE and one for non-RE (I would rather we quit calling the non-RE thing "CO" since not all non-RE stuff is commercial). This will cause the usage of network numbers to increase dramatically, hastening the time that we run out of address space. This would break things very quickly. Maybe the hue and cry would convince the powers-that-be that things ought to change. It would really be a shame to be forced to break the very thing many have spent significant parts of their life to build just so we could get it fixed. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392
participants (3)
-
brian@lloyd.com
-
mathis@pele.psc.edu
-
Vince Fuller