Sprint BGP filters in 207.x.x.x?

Aside from what Daniel says about Sprint and MCI's routing policy
mismatch, this statement is interesting on another level. For Dan says:
MCI aggregates all its customer's routes into /19's. This is new is it
not? Also it says *MCI* does the aggregating and not the customer.
Would someone please explain how this differs from what I understand to
be Sprints policy which says (i believe) that it is the CUSTOMER's
responsibility to aggregate the routes they present to sprint???

Why would MCI do the aggregating? Is such mci policy good for mci or
good for the customer or equally good for both?

If one gets a /19 and redistributes it to 8 new ISP customers, it is
your responsibility to make sure that you only redistribute that /19 -
and not any more specifics. If you *know* what those /19s, /18s, ...
are, you can put specific aggregate statements into the peering routers.

It's trickier when you have some contiguous space (customer X announces
a /23 to you and customer Y announces a /23 - and the two /23s can be
merged into a /22) that comes from customer's space allocations. You
have to detect that aggregation is possible and then statically insert
it - and check that it won't break anything (i.e. that customer X doesn't
need only the /23 announced because he wants it to override a larger /22).

But certainly when you are directly allocated address space, you have
a responsibility to aggregate announcements from your customers who are
in that space yourself.

It doesn't hurt the customer, since the space is administratively yours -
if they want to multi-home, their other provider (who obviously does not
own the same /19 or /18 or ...) will announce the more specific /22 route
and things will be fine for that customer (except that if it's newer
address space, Sprintlink customers won't see the second provider's path
to that /22 unless the second provider *is* Sprintlink).