Sprint and peering points

garlic@garlic.com writes:

So by making the change Sprint unilaterally shifts the transit packets from a
public peering point away from themselves.

So if a *customer* asks Sprint, either directly, or via a
community like 1755:12xx (see whois -h whois.ripe.net AS1755),
is this "unilateral" on the part of Sprint?

What would have been nice is for Sprint to tell its customers it was doing
this. Then I would have expected the change in inbound traffic flows and
taken action.

If it were a paying customer who indicated that Sprint should
prepend, do you feel Sprint should be obliged to inform all
customers beforehand? Is your answer different in the case
of non-revenue connections ("peers")?

How should this be done in the event that "prepend-request"
BGP communities are being used by a network connected to
Sprint, given that the other network may set or not set
the attribute for any given prefix at any given time?

As it was, I opened a trouble report and wasted a lot of time looking
for a problem.

Welcome to the Internet, it has routing complexity growth over time!


Let's require every BGP router of significance to peer with a route-view

... not :wink: