ANS to CIX Interconnection

Thu Oct 1 21:41:08 UTC 1992

> From:    "Milo S. Medin" (NASA ARC NSI Office) <medin at nsipo.nasa.gov>
> To:      mak at merit.edu
> CC:      bjp at sura.net, regional-techs at 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