Note that the 94 new networks will potentially be generating traffic which does not comply with the NSFNET Acceptable Use Policy. The new network numbers will be announced by the ANSNET to the peer networks that are both ANS CO+RE and CIX members. Those regionals or midlevels who are using default routing to point their traffic to the NSFNET backbone may wish to explicitly prohibit traffic between their users and these new networks if their internal policies require it. This may be done by either internal means (eg. informing users), or by filtering in routers operated by the midlevel network. Regionals may contact Merit to discuss other options for blocking this traffic if required.
Is there a reason why complete information is in the ENSS rather than the CNSS? My understanding of the agreement is that it is for the benefit of ANSnet and the CIX, so why should the regionals have to adjust the way they are set up? I'm not just saying this to be contrary (Honest). I am really interested in knowing why this method was chosen. As others have pointed out it move the burden of enforcing policy restriction to individual AS pairs. Comments? I am also interested in hearing what people pointing default at NSFnet plan to do? Brad Passwaters (301)(982-3214) SURAnet Operations bjp@sura.net <My name, my opinions.>
From: bjp@sura.net To: mak@merit.edu, regional-techs@merit.edu
Is there a reason why complete information is in the ENSS rather than the CNS S? My understanding of the agreement is that it is for the benefit of ANSnet and the CIX, so why should the regionals have to adjust the way they are set up? I'm not just saying this to be contrary (Honest). I am really interested in knowing why this method was chosen. As others have pointed out it move the burden of enforcing policy restriction to individual AS pairs. Comments?
Brad, You are correct that our interpretation of the AUP situation is that the burden is on the regionals/midlevels to enforce the policies as they apply to their institutions. This can be done by simply issuing a public statement to all users that people should only use the NSFNET for purposes of research and education. Or it can be done a bit more drastically by filtering out routes. The actual implementation of filters needs to be done in the regional's peer router when default routing is used. Does this help?
I am also interested in hearing what people pointing default at NSFnet plan to do?
Some are not going to filter at all, some are going to implement static routes to "black holes", and others have yet to talk to us.
Brad Passwaters (301)(982-3214) SURAnet Operations bjp@sura.net
<My name, my opinions.>
--Mark
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 networks 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 conflict 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
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
Mark, the main problem for us is if you don't filter out the 97 some odd nets out of the AS 1957 routes you send us. If you are willing to do that, then we still don't have any new administrative load, and from NSI's point of view, we're happy. Did I read your statement right? If so, we'd definitely like to take you up on this offer! You say: "For regionals using default, it isn't possible to prevent traffic from being sent from the regional to the CIX." This is true, given a certain set of assumptions, such as that the ENSS and CNSS's having the same set of routes. If the ENSS did not install the 97 nets etc, in it's routing table, then since it didn't have default, it would generate net unreachable messages and the traffic wouldn't flow. Given that I thought this kind of thing was possible given your implementation and use of IBGP and such, then this shouldn't be that hard. Again, please correct me if I'm offbase here. You certainly could argue that this sort of thing is necessary for ANS to serve it's member network's needs for CO+RE service. The real question is whether or not it is possible to do this and not increase the administrative load of non-participating regionals under your NSFNET agreement. The key to resolving the latter question is how much flexibility you guys have with the import and export of routing information into the routing tables of the ENSS's, and to be honest, I have only peripheral knowledge of the current way routes are sent around inside the T3 system (not because you guys are being secretive, just that I haven't been following this very closely due to work load problems). Thanks, Milo
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 main problem for us is if you don't filter out the 97 some odd nets out of the AS 1957 routes you send us. If you are willing to do that, then we still don't have any new administrative load, and from NSI's point of view, we're happy. Did I read your statement right? If so, we'd definitely like to take you up on this offer!
See Steve Widmayer's message about the above.
You say: "For regionals using default, it isn't possible to prevent traffic from being sent from the regional to the CIX." This is true, given a certain set of assumptions, such as that the ENSS and CNSS's having the same set of routes. If the ENSS did not install the 97 nets etc, in it's routing table, then since it didn't have default, it would generate net unreachable messages and the traffic wouldn't flow. Given that I thought this kind of thing was possible given your implementation and use of IBGP and such, then this shouldn't be that hard. Again, please correct me if I'm offbase here.
While this might be possible this scheme would cause some administrative problems. Currently the backbone ENSS's and CNSS's carry full external routes in their tables, with each ENSS having an IBGP session with all other nodes. I think a better long term solution would be to try to move away from using default and on to full routing information exchange at AS borders (using aggregation of course). An example of the kind of problem we would run into using the ENSS-filtering approach is that all peers of that ENSS would have to use the same policy.
You certainly could argue that this sort of thing is necessary for ANS to serve it's member network's needs for CO+RE service. The real question is whether or not it is possible to do this and not increase the administrati
ve
load of non-participating regionals under your NSFNET agreement. The key to resolving the latter question is how much flexibility you guys have with the import and export of routing information into the routing tables of the ENSS's, and to be honest, I have only peripheral knowledge of the current way routes are sent around inside the T3 system (not because you guys are being secretive, just that I haven't been following this very closely due to work load problems).
Thanks, Milo
Still wearing my asbestos boxers (just in case), Mark
--> From: "Milo S. Medin" (NASA ARC NSI Office) <medin@nsipo.nasa.gov>
Mark, the main problem for us is if you don't filter out the 97 some odd nets out of the AS 1957 routes you send us. If you are willing to do that, then we still don't have any new administrative load, and from NSI's point of view, we're happy. Did I read your statement right? If so, we'd definitely like to take you up on this offer!
If you don't want to hear about the ~97 nets AND you don't do default routing then you are fine. In other words, you read Mark correctly and are fine. This situation is not a problem UNLESS you point default.
You say: "For regionals using default, it isn't possible to prevent traffic from being sent from the regional to the CIX."
Pointing default is, in a sense, like stating that you trust the network to which you default (and all of its peers) with your packets. You have given up your only means of controlling your traffic. I've even heard someone state that "pointing default is a kludge." If not a kludge, it is certainly a substitute for horsepower (which may be a financial even technical consideration) that affords no mechanism to enforce one's own policy. You can then ask someone else to enforce your policy for you but if they say they can't...
This is true, given a certain set of assumptions, such as that the ENSS and CNSS's having the same set of routes. If the ENSS did not install the 97 nets etc, in it's routing table, then since it didn't have default, it would generate net unreachable messages and the traffic wouldn't flow. Given that I thought this kind of thing was possible given your implementation and use of IBGP and such, then this shouldn't be that hard. Again, please correct me if I'm offbase here.
You're both correct and offbase. It is true that IF the ENSSes did not install the routes you would have solved the problem FOR EVERYONE USING THE ENSS (all of whom may not have the same policy restrictions). It is not true that "given your implementation and use of IBGP and such" ANS can do this. As I understand it, intra-domain protocols (IBGP, IIDRP) have as a design basis the assumption that all internal neighbors have full disclosure of routing information between themsleves. Regardless, the implementation that ANS uses does not support this feature. One option (as Vince Fuller pointed out while I typed this) is to do IBGP with CNSSes and have each ENSS peer with both the regional and the CNSS IBGP mesh. This is effective but ugly. Besides slowing the propagation of routes within the backbone, it adds 2 ASes to the AS path, uses up AS numbers like they are going out of style, and accomplishes nothing more than a regional could if it had the horsepower to enforce its own policy restrictions.
You certainly could argue that this sort of thing is necessary for ANS to serve it's member network's needs for CO+RE service. The real question is whether or not it is possible to do this and not increase the administra tive load of non-participating regionals under your NSFNET agreement. The key to resolving the latter question is how much flexibility you guys have with the import and export of routing information into the routing tables of the ENSS's, and to be honest, I have only peripheral knowledge of the current way routes are sent around inside the T3 system (not because you guys are being secretive, just that I haven't been following this very closely due to work load problems).
Yes, one could argue that but as I stated it is not possible to do this without kludges and even with such kludges, it would still be effective only on an ENSS (router) basis and not on an AS basis. I believe, as Mark said, that currently the architecturally clean thing to do is to try to get each AS to control their own policy, hopefully in a spirit of cooperation and disclosure with its peers. That way the backbone can forward packets as effectively as possible, stopping only to do minimal verification of ownership of networks and regionals can make/implement decisions whenever they choose without a backbone provider serving as middleman.
Thanks, Milo
I guess I see this as a step in the right direction. But then I dream of an AUP-less world full of white picket fences... I wear only my own hats and I route my opinions under the same policy, eric
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
participants (4)
-
bjp＠sura.net -
mak -
Milo S. Medin -
R. Eric Bennett