- Test - lists.nanog.org

Re: ANS to CIX connection
by Milo S. Medin 02 Oct '92

02 Oct '92

Hmm, this message bombed for some reason yesterday, and it looks like it didn't make it to anyone on the list. Since it sort of clarifies what I'm trying to say, I'm forwarding it on... Thanks, Milo ------- Forwarded Message Return-Path: postmaster(a)merit.edu Return-Path: <postmaster(a)merit.edu> Received: Thu, 1 Oct 92 12:26:04 PDT from kiddo.merit.edu by nsipo.arc.nasa.gov (4.1/1.5) Received: Mon, 31 Aug 92 05:38:55 -0400 from merit.edu by kiddo.merit.edu (AIX/1.6) Date: Mon, 31 Aug 92 05:38:55 -0400 From: Mail Delivery Subsystem <postmaster(a)merit.edu> Subject: Returned mail: unknown mailer error 2 Message-Id: <9210011927.AA16009(a)kiddo.merit.edu> To: <medin(a)nsipo.nasa.gov> ----- Transcript of session follows ----- ----- Unsent message follows ----- Received: Thu, 1 Oct 92 15:27:16 -0400 from merit.edu by kiddo.merit.edu (AIX/1.6) Return-Path: <medin(a)nsipo.nasa.gov> Received: from cincsac.arc.nasa.gov by merit.edu (5.65/1123-1.0) id AA18964; Thu, 1 Oct 92 15:22:55 -0400 Received: Thu, 1 Oct 92 12:22:53 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Message-Id: <9210011922.AA25507(a)cincsac.arc.nasa.gov> To: skw(a)merit.edu Cc: mak(a)merit.edu, bjp(a)sura.net, regional-techs(a)merit.edu Subject: Re: ANS to CIX Interconnection In-Reply-To: Your message of "Thu, 01 Oct 92 04:47:26 EDT." <9210010847.AA08821(a)home.merit.edu> Date: Thu, 01 Oct 92 12:22:52 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) <medin(a)nsipo.nasa.gov> Ok, I think I'm beginning to understand this better. So, the AS 1957 announcements will not be used as backup for CIX attached AS's to non CO+RE subscribers? It's only for use for the commercial types. One reason why I think some people are very interested in this issue of default routing to the NSF causing reachibility to CIX connected facilities is that as I understand it, there is a charge associated with the CO+RE service, which is supposed to go into some sort of pool to be distributed in various ways. Now, if a regional doesn't sign the CO+RE agreement, but because of default routing sends IP packets to CIX connected sites to their local ENSS, will they be charged for this in some manner? If not, then why should any regional be a CO+RE subscriber? Since they mostly point default at the ENSS already, and then they get connectivity without charge. You see, I think you guys have the greatest reason to not have AS 1957 routes installed in the routing tables of the various ENSS's whose members don't subscribe. Otherwise, those attached AS's could use the CO+RE service, and without an agreement, you could not be compensated for this. And I should point out that if you aren't compensated for this by the CIX folks (no settlements there) and by the regionals (because they just point default at you), then NSF would be placed in the position of supporting non-AUP traffic on resources it pays for. Now, you could legitimately point out that the since the CIX doesn't have a default pointing at the ENSS, that the packets from the non CO+RE subscribing regional would not get back that way, because you would not be sending those CO+RE nets to the CIX. However, I would venture a bet that most of the AS's which attach to the CIX have default pointing at some ENSS, or a router that has total routes from the ENSS. This means that the regional would route to the CIX net via the ANS-CIX interconnect, and then back from the CIX member via their "normal" internet path. So you still get connectivity, albeit with an asymmetric path. This is why some AS who doesn't want CIX connectivity established basically MUST not have a default pointing at an ENSS, but have to recieve total routes (- AS 1957) and run with no default. Because the reverse path will likely still work by following default back to the NSS system. This isn't a problem for us, but might be a problem for others. Now, there are other problems even if you go ahead and not flood AS 1957 routes into the ENSS's that non-CO+RE AS's attach to. For example, if one AS which peers with an ENSS goes the CO+RE route, then the ENSS would have the AS 1957 routes in it's routing table. But since it's the case at several sites that multiple AS's peer with the ENSS, a non CO+RE subscriber AS could point default at the ENSS and gain connectivity with CIX nets because the ENSS had those routes to support the CO+RE subscriber. Things get very complicated here. I presume there is no way you can send a bill to someone you don't have a contract with, so you really need some way of enforcing the charging scheme that's been developed, else you guys will have to result in filtering at the packet forwarding level to prevent that traffic from flowing. Do the NSS routers let you do that? Again, havi ------- End of Forwarded Message

1 0

Re: ANS to CIX Interconnection
by Jordan Becker 02 Oct '92

02 Oct '92

> It seems to me that something is missing here. Perhaps I missed it, > but I don't think I've seen anything about what CO+RE will be > announcing to the CIX. I seem to recall a statement that the CIX does > not use default, but that's it. > > What does ANS CO+RE plan on announcing to the CIX? > > Ross Ross - there are several service providers that are directly homed into ANSNET (e.g. regionals) that are applying for CIX membership status, and plan to use ANSNET as a transit to reach the CIX. CO+RE will announce all of these service providers routes to the CIX. I presume that the CIX trade association will publicize the membership of these service providers as they join. Jordan

1 0

Re: ANS to CIX Interconnection
by rrv＠cody.cso.uiuc.edu 02 Oct '92

02 Oct '92

It seems to me that something is missing here. Perhaps I missed it, but I don't think I've seen anything about what CO+RE will be announcing to the CIX. I seem to recall a statement that the CIX does not use default, but that's it. What does ANS CO+RE plan on announcing to the CIX? Ross

1 0

ANS-CIX Interconnection
by Jordan Becker 02 Oct '92

02 Oct '92

> From: bjp(a)sura.net > Subject: Re: ANS to CIX Interconnection > Cc: regional-techs(a)merit.edu > Date: Wed, 30 Sep 1992 20:52:58 GMT > To: mak(a)merit.edu > > Can you tell me why you aren't keeping complete information in the > CNSSs instead of the ENSSs? Both ENSSs and CNSSs normally have complete routing information. The ENSSs will selectively announce commercial destination networks only to the participating service providers. It is possible for an ENSS to have partial routing information. However, one problem with this is that multiple regionals peer with the same ENSS at several locations. If an ENSS had partial information to administer some restriction policy, this would affect all regionals that peer with that ENSS. That might adversely affect those regionals that wish to receive the additional routes, and would certainly result in more work to maintain the policy routing database, and routing software, not to mention the management of consensus between each regional that shares an ENSS. There are ways for a regional to block this traffic, even if they continue to use default routes (e.g. create a static route for the commercial destinations to "black hole" the traffic). However it does require some effort by the regional as several people have correctly pointed out. > I can't see the problem you are solving by > engaging in this activity. The basic problem is to give remote CIX members (e.g. some regionals) access to the CIX using the ANSNET as transit. Jordan

1 0

Re: ANS to CIX Interconnection
by Vince Fuller 01 Oct '92

01 Oct '92

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. Why not split the ENSS's out of the IBGP "cloud" and use external-BGP between the ENSS's and CNSS's? This would likely require that an addition AS number and non-140.222 network be assigned to each ENSS, but it seems to fit more logically into the CNSS/ENSS architecture. It would also greatly reduce the number of IBGP sessions inside the T3 backbone. Comments? --Vince

1 0

Soviet Network
by Jordan Becker 01 Oct '92

01 Oct '92

> From: Rick Adams > > So, to sum up, ANS is discriminating against users of a network > because of their natural origin and there is no basis in law to > support this position. Pretty xenophobic for a group that claims to be > an international provider. As a matter of business policy, we attempt to ascertain the country of origin for any network announced over the ANSNET backbone. We already know that it is illegal (according to Dept. of Treasury and Commerce) for us to exchange traffic with certain countries under any circumstances (e.g. Irag), and only when granted a special license for other countries (e.g. Libya, North Korea, Cuba, Vietnam, and Cambodia). CIX assumes no liability or responsibility for the networks they announce to ANSNET. We do not get up-to-date information on the nets announced by the CIX including the country of origin other than by inspecting dumps of the CIX router tables. We only recently became aware of the former Soviet Union network announcement from the CIX routing table dump. Until recently, the Soviet Union was on one of the dept. of Commerce restriction lists. While we have recieved some preliminary advise that carrying transit traffic to/from the former Soviet Union is ok, we are still awaiting verification through independent counsel that there are no other legal liabilities. We expect a positive reply to this shortly (perhaps by the the actual config. run). We do not view this as a matter of paranoia (although others may), and this has nothing to do with NSF, other than they have asked us not to announce this net to the federal agency networks. We view this verification simply as prudent business practice. Jordan

1 0

Re: ANS to CIX Interconnection
by skw 01 Oct '92

01 Oct '92

>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! > Milo, The current plan is to NOT explicitly announce AS 1957 routes to anyone except a subset of ANS CO+RE/CIX members. We also agreed not to announce the CIX nets to the T1 via the T1-T3 interconnect, to avoid having the routes leak into sites via the interconnect. So, sites like NSI that don't do default routing will not suffer an increased administrative burden in any way. --Steve W.

2 1

Re: ANS to CIX Interconnection
by Curtis Villamizar 01 Oct '92

01 Oct '92

> So what you're saying then is that you are not an independant entity and > are require to follow federal policy. > > NSF has a policy against it. that has nothing to do with legality. > > NSF also has a policy against carrying commercial traffic? Did you > adopt that? > > You are not being conservative. You're way into paranoid. > > So, to sum up, ANS is discriminating against users of a network because of > their natural origin and there is no basis in law to support this > position. Pretty xenophobic for a group that claims to be an international > provider. > > Now I've seen everything. Gordan Cook forging mail as Rick Adams. ;-) As I understand it this represents a compromise between the policy that the regionals and other direct attachments are required to enforce their applicable APU in whatever way they see fit (which in some cases is to do nothing more than issue a statment to users that outlines the AUP), and the strong sentiment among government agencies and the NSF not to have the xSU net announced until they are prepared to deal with it more thoroughly than plain vanilla commercial traffic. Whether this has basis in NSF policy or law is not something that Mark (or I) really cares that much about (unless it does turn out to be based on law and we get into big trouble). I'm not sure if this is even permanent, but I suspect (speculation alert!!!) that once there is a technical solution that prevents routing between the feds doing there state of the art FIX default route thing (and anyone else that doesn't want to talk to them), and the other major international providers doing their default route thing, we might just pipe the xSU net in and let them do business in the US and talk to US R&Es that are willing to talk to them. Until then we will be exersizing prejudice against the xSU. What are we talking about here folks - one class C net? If you need access to that net right now, join the CIX - 'cause ye can't get thar frm here. Curtis <<<INSERT BIG DISCLAIMER HERE - I don't speak for ANS>>>

2 1

Re: ANS to CIX Interconnection
by rick＠uunet.uu.net 01 Oct '92

01 Oct '92

> One of the new networks originates in the former Soviet Union, > and traffic between US Government sponsored networks and the former > Soviet Union is prohibited at this time. Therefore accordingly, the > ANSNET will not re-distribute or announce any routes to this network. Well, the obvious question is what does this have to do with anything? The whole point of the CIX is to not have to screw around with outdated government policy. So, either ANS CO+RE isn't REALLY the commericial separate entity it claims to be or the above statement makes no sense and should be retracted. Which is it? ---rick

2 4

Re: ANS to CIX Interconnection
by bjp＠sura.net 30 Sep '92

30 Sep '92

>>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? > > 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? It does provide something of a clarification BUT I still have many questions. Does this mean that NSFnet will now take NACRs for any network and we no longer need to claim that people will abide by the AUP? This seems to me to be a radical change in policy. What is the reason for this shift? If people are still bound by the AUP and regionals can not submit NACRs for non AUP sites than it appears to me that we now have two classes of citizens on the Net. Those that can transmit any kind of packet and make the rest of the people bear the burden of preventing traffic we don't want and those of us who can't :-( I can understand that Merit does not want to enforce specific regional access policys *but* the regionals have been able to count on getting traffic that fits a specific AUP requirement from the NSFnet. This is no longer true. Can you tell me how this change benefits the regionals or even NSFnet? Can you tell me why you aren't keeping complete information in the CNSSs instead of the ENSSs? I can't see the problem you are solving by engaging in this activity. Brad Passwaters (301)(982-3214) SURAnet Operations bjp(a)sura.net <My name, My opinions>

1 0