ANS to CIX Interconnection

Thu Oct 1 19:22:52 UTC 1992

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 
(-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, having a clear set of objectives and goals from all the different
players at the table would be very helpful.  Routing is configured to
support policy, so it's important that policies be clearly understood.
I don't know whether or not the design you guys have proposed meets ANS's
or MERIT's requirements, but I have reason to believe that all parties
are not in sync on what the end result is supposed to be and what the 
various constraints are.  I do think that if such goals and objectives were
all agreed to by the various parties involved, that a solution should be able
to be achieved.  Of course, there are limits that you have to deal with
if you are using IP routers as the core of your switching fabric, but 
I won't go into that now... :-)

						Thanks,
						   Milo