On Feb 8, 2006, at 12:30 PM, william(at)elan.net wrote:
"Transit" is when one entity sends the routes on to other
organsiations, often with money involved.
More commonly understood is that transit involves one ISP sending all
of its BGP routes and allowing any traffic to be send from ISP A
for for delivery to destination.
However number of organizations (say cogent buying from verio) only
get routes from certain specific ISPs that they can not otherwise
reach
which is again scenario "ISP A buys from ISP B to get to ISP C" but
most people call this transit in this case...
The reality is that for outside observer (especially if you look at
the net as whole), there is no clear view that separates peering from
transit and most correct is to consider everything to be peering with
various differences being as to what kind of filters are deployed and
where and how money is being exchanged.
Disagree.
If you pass routes received from AS$I to AS$J, then you are providing
transit to either $I or $J. Period. This is perfectly clear, even
for an "outside observer".
What gets interesting is when you pay AS$N for access to only AS$N's
prefixes. That looks like peering from the outside, but most people
would call it transit.
However, that does not make all transit equal to peering. In fact,
purchasing transit vary rarely involves BGP, so it should not be
considered peering even as a special case.
If you want to define it as such, all BGP sessions are "peering
sessions", but we are not talking on the protocol level here. There
is nothing in the protocol about transit, and using protocol level
definitions when talking about business relationships makes about as
much sense as arguing over Mac OS vs. Windows when discussing wire
transfers.
Also, just because it looks like something to an "outside observer"
does not make it so. Transit vs. peering is a business relationship,
and is defined by the parties involved, not the protocol used or how
people outside view it.
--
TTFN,
patrick
