[189946] in North American Network Operators' Group
Re: intra-AS messaging for route leak prevention
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Fri Jun 10 13:26:40 2016
X-Original-To: nanog@nanog.org
Date: Fri, 10 Jun 2016 10:19:29 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: nanog@nanog.org
In-Reply-To: <CAL9jLabc8ONCHERsOM=nkkBntJgwzCqzUm2Lw4Uwuf3Y7k-=gQ@mail.gmail.com>
Errors-To: nanog-bounces@nanog.org
--2fjX3cMESU3XgGmZ
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri 2016-Jun-10 13:08:48 -0400, Christopher Morrow <morrowc.lists@gmail.=
com> wrote:
>On Fri, Jun 10, 2016 at 1:05 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
>
>>
>>
>> On 10/Jun/16 16:47, Christopher Morrow wrote:
>>
>>
>>
>> so I can't be a customer of you and a network you peer with?
>>
>>
>> You can, but we won't learn your paths via the peering session we would
>> have with your other ISP.
Wouldn't "learn but depref" be preferred and more common? E.g. customer=20
routes get tagged with "customer route" community and local-pref'd to 150=
=20
or something; peer routes get tagged with "peer route" community and local=
=20
pref'd somewhere below that.
Else any of your other customers that are single-homed to you can't reach=
=20
your dual-homed customer A in cases where customer A's link to you is down,=
=20
but customer A has other transits with whom you peer?
Unless it's mitigated by you accepting customer A's prefixes from any=20
transits you have, which at the least seems sub-optimal (now reaching them=
=20
via transit rather than peering if customer A's circuit is down) or=20
possibly also up-ended if you also similarly apply "don't accept customer=
=20
prefixes from transits".
No?
>>
>>
>oh, so I didn't misunderstand.. that makes 'backup isp' less useful, no?
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
--2fjX3cMESU3XgGmZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJXWvahAAoJEFsnhBAb2KmA2a4P/j4KGUcdR0dODMfMIvgSa6tP
a3YhLmdWmIuj2rZMmQgui4bt9H7elMiA2JgJxUZJ3qfApHq6+xNyBvXg7K6ddAl+
noCaj9XeKiJNSRbggMWhxHuZKEzQtxNw3aZbXIEeegfK88NhFJHZyW7WMZDVy8nM
JvNAFdvtb/tP+qpcaKYusuxEoLlF+p9Aq9cK+AFMLuZoXbLZW4c/7PjxJLVbOUPH
ucZGB4eHhzeuUAXs06mY/PbNK5WMhSDq5IeA8e7Abf0SG9vd7b3GxAe3zFLFkWMu
y2kptM8Egn9hX9Eiz1HGFw6mAGIjo17DbwU4OQCPBcXoGcyaKnW7smz+V1rUd0rX
Phx5sVjwZYFTBBHbQwyqrH2P4L9BHB8aubXvjFOpLuxG63m+r+rAGuxugfPOx1dS
Anv+qG++bnQKg0PbPr1/gyYkX/G4YcEFekFP6VHr2ZXoVtRN7cfHxAPxOxNSPIPj
XPwf8t7cUyLcY4fuo/knEs5m/krTKv6XZwZt3n+d5p4gmY772z2UISd8T/39d2eK
ZllSF19ILaMNSH/vtkp5r2ANqjf/+y2TeD3LAoBQAVdkR3iiF3LIjoHS6UQt2L0q
2CrBol+W5/v3F4NN3rEnZ9lgv/hC0RPbFYDEg6/nRRt/pOS7kSjBykeeLye6+6CI
svl5sufQzvi4VY1b0M+l
=T9V0
-----END PGP SIGNATURE-----
--2fjX3cMESU3XgGmZ--
