North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Worldly Thoughts

  • From: Curtis Villamizar
  • Date: Fri May 10 19:30:43 1996

In message <[email protected]>, Alan Hannan writes:
>   So, WHY would an NSP enter into a peering agreement with another
>   person?  Why, to profit from the one side of the connection, to
>   enable an entity [labeled A] to talk with some other entity [labeled 
>   B].  In most cases, NSP1 had as customer A, and NSP2 had as customer B,
>   and obv. it was in their best interest to meet somewhere to talk
>   to each other.  NSP1 added value to A, by providing a path to B.
>   NSP2 added value to customer B by providing a path to A.

Maybe because their routers fall over beyond some number of direct
peers and they have a problem with the idea of going through the RA's
router servers to avoid that problem (whether the problem is real or
imagined, present company included - not sure if a smiley or a frown
is needed here).

This results in a need/desire to prioritize.

Let me turn the question around a bit.  Suppose N small providers peer
at M places and together represent p% of the Internet.  If they simply
appear at one NAP and don't contract for transit, they may reach
100%-(%p/(M-1)) of the Internet.  Is that something to encourage?  If
they must contract for transit and as a result reach all major
interconnects, they get 100% (possibly minus a small epsilon for other
reasons).  They then don't need to be at any of the NAPs.  Are some
providers trying to show up at one NAP only with the aim of not
contracting for transit through anyone even though they can't really
reach others like themselves at a different interconnect?


ps- this is a tangent but - I think ANS has a problem with using the
RS since at one point we announced everything to the RS and started
giving transit connectivity to people that were not transit customers
of ANS.  The technical barrier to fixing this at that time was an
inability to express outbound policy adequately (no support for
as-paths).  This technical barrier is almost gone except we have code
that uses as-macros and we'd have to exapnd the as-macros and
expresses this policy in our aut-num.  So the ball is in our court
(along with too many others).  The other issue is we have no
management access to the RS and so if any of this isn't configured
and/or working right on the RS we can't easily tell if it is.  The
issue in general for most providers is they want direct control over
their peerings and import and export policy.

pps- I suppose the other solution is to get routers that can handle
the peerings directly.  :-)
- - - - - - - - - - - - - - - - -