[36258] in North American Network Operators' Group
Re: Sprint and peering points
daemon@ATHENA.MIT.EDU (Josh Richards)
Sat Mar 31 15:04:44 2001
Date: Sat, 31 Mar 2001 11:51:15 -0800
From: Josh Richards <jrichard@cubicle.net>
To: nanog@merit.edu
Message-ID: <20010331115114.A23972@datahaven.freedom.gen.ca.us>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH"
Content-Disposition: inline
In-Reply-To: <20010331111743.A23915@datahaven.freedom.gen.ca.us>; from jrichard@cubicle.net on Sat, Mar 31, 2001 at 11:17:44AM -0800
Errors-To: owner-nanog-outgoing@merit.edu
--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
* Josh Richards <jrichard@cubicle.net> [20010331 11:23]:
> * Roy <garlic@garlic.com> [20010331 08:13]:
> >=20
> > Needless to say I am a bit pissed at Sprint for doing this and not tell=
ing
> > me. I had been a fan of Sprint until this happened. Anyone else out t=
here
> > seeing the same problems? Any ideas on how to cure it
>=20
> You could prepend your non-Sprint upstreams.=20
Oh, you said you're "pissed at Sprint for doing this and not telling me".
Routing changes all of the time though depending on=20
topology/contracts/politics/PoPs/peers/etc. I don't see any easy _useful_
way for transit providers to communicate this information to their=20
customers. I also may not be looking hard enough.
<thinking out loud>
Keep in mind that every multi-homed customer is going to be affected in=20
very different ways by changes such as this. It will depend a lot on who=
=20
the other transit providers are. I'm not saying that knowledge of these=20
types of changes is not useful, I'm saying that to convey these types of=20
changes in a useful manner would appear to be difficult.
For example, supposed Sprintlink conveyed (via Web/e-mail/whatever) the=20
following to you just before making the change:
We are bringing up some new private peering connections. As a result we=
=20
will be migrating much of our existing traffic destined for ASNs 209, 701,
and 1 and exchanged on the public fabrics at MAE-West, MAE-Eest, and PAIX
to private links. The public links will remain in place with prepending=
=20
to encourage usage of the private links. We will be prepending three=20
times. Happy route tweaking!
Would you have known just how this would effect your other upstreams? Do
you know your upstreams' routing policies at every interconnect they have?
I guess you could make your public routing policy detailed enough to includ=
e=20
specifics on each peer. That might do it -- but realize how long this polic=
y=20
could be for a network of reasonable size (hundreds, if not thousands of BGP
neighbors -- from peers to all customers). Actually, what about RADB?
I'll also warn you that I've not had any coffee as of yet. I'll go do that=
=20
now and likely come back to several replies pointing to errors in my=20
reasoning above. :-)
</thinking out loud>
-jr
----
Josh Richards [JTR38/JR539-ARIN]
<jrichard@geekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us>
Geek Research LLC - <URL:http://www.geekresearch.com/>
IP Network Engineering and Consulting
--7JfCtLOvnd9MIVvH
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjrGNSkACgkQ8VgqD3XNPNVWvACeKBMZVW4LbOXcV4gHQWrMZqWn
20EAoL5UejQk9Kzjxq2ic8I1lLx38Vnx
=Kdzm
-----END PGP SIGNATURE-----
--7JfCtLOvnd9MIVvH--
