[195540] in North American Network Operators' Group
Re: Virtual or Remote Peering
daemon@ATHENA.MIT.EDU (Mike Hammett)
Thu Aug 17 17:23:25 2017
X-Original-To: nanog@nanog.org
Date: Thu, 17 Aug 2017 16:23:20 -0500 (CDT)
From: Mike Hammett <nanog@ics-il.net>
To: Jay Hanke <jayhanke@gmail.com>
In-Reply-To: <CAK6zc0ms2jV7Kzwcp69vG2ROrcsBPDV33C9+peQXVojcrKtKdQ@mail.gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
I guess I didn't go on to say more about the router situation, but I meant =
an official network presence, diverse paths to other POPs, etc. for the fir=
st entry.=20
-----=20
Mike Hammett=20
Intelligent Computing Solutions=20
http://www.ics-il.com=20
Midwest-IX=20
http://www.midwest-ix.com=20
----- Original Message -----
From: "Jay Hanke" <jayhanke@gmail.com>=20
To: "Mike Hammett" <nanog@ics-il.net>=20
Cc: "NANOG list" <nanog@nanog.org>=20
Sent: Thursday, August 17, 2017 9:35:28 AM=20
Subject: Re: Virtual or Remote Peering=20
I think you are talking about different applications of remote peering.=20
If you connect to a remote IX via transport the routing decision is=20
more along the lines is this packet destined to me. Having a router=20
sitting in the "remote" colo is of little value. It would not help to=20
keep the traffic local as there are only two paths. The router would=20
just forward between the ports on either side. A common application of=20
this is a "backup" IX to pick up content in the event of a failure at=20
the primary IX. A wave service is just a very long cross connect in=20
this regard.=20
If you provide services across the IX and start bouncing things=20
through remote ports (that could stay local). That is a different=20
animal.=20
Jay=20
On Thu, Aug 17, 2017 at 6:41 AM, Mike Hammett <nanog@ics-il.net> wrote:=20
> A company you have a contractual arrangement with vs. random operators of=
which neither you nor the end party have any relationship with. Which one'=
s unreliable, again?=20
>=20
> From a technical perspective:=20
> router located with IX > wave to IX > switched PtP\PtMP to IX > remote pe=
ering service > transit=20
>=20
> Fiscally, it's almost the other way around, with where transit goes being=
variable based on locations and volumes.=20
>=20
>=20
>=20
>=20
> -----=20
> Mike Hammett=20
> Intelligent Computing Solutions=20
> http://www.ics-il.com=20
>=20
> Midwest-IX=20
> http://www.midwest-ix.com=20
>=20
> ----- Original Message -----=20
>=20
> From: "M=C3=A5ns Nilsson" <mansaxel@besserwisser.org>=20
> To: "Mike Hammett" <nanog@ics-il.net>=20
> Cc: nanog@nanog.org=20
> Sent: Thursday, August 17, 2017 12:42:21 AM=20
> Subject: Re: Virtual or Remote Peering=20
>=20
> Subject: Re: Virtual or Remote Peering Date: Wed, Aug 16, 2017 at 08:02:4=
7AM -0500 Quoting Mike Hammett (nanog@ics-il.net):=20
>=20
>>>> How well does this service work? I understand it usually involves poin=
t-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds li=
ke a service for ISP that would like to peer, but have relatively small vol=
umes for peering purposes or lopsided volumes.=20
>=20
>>> Its like buying regular ip-transit, but worse.=20
>=20
>> That seems to be a rather lopsided opinion.=20
>=20
> You get connections to other operators over an unreliable path that you=
=20
> have no control over, and the opportunities to keep traffic local are=20
> limited. Adding to that, it is all your fault since your provider does=20
> not do L3 and can claim a very passive r=C3=B4le in the process.=20
>=20
> Like transit, but worse.=20
>=20
> --=20
> M=C3=A5ns Nilsson primary/secondary/besserwisser/machina=20
> MN-1334-RIPE SA0XLR +46 705 989668=20
> YOW!! The land of the rising SONY!!=20
>=20
