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

Reply via email to