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

MCI aggregates all its customer's routes into /19's. We have just
received our first block of address space from the 207.x.x.x range. If
you continue to filter at /18's for the 207.x.x.x range, you won't be
able to reach all of MCI's customers.

Needless to say MCI would appreciate it if you'd change your policy to be
/19's, and I'm sure Sprint's customers would appreciate it as well.

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.

That may hold true internally, however, I suspect that externally, they
announce only /16's or /15's. Of course, I could be wrong.

What I see right now, is only one announcement from the 207 block...a /19
coming from netaxs, and then some customer of PSI is announcing 5 or so
/24's in the 208 block!

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???

Sprint already proxy-aggregates for many of their customers. Most of them
probably don't realize it. It doesn't even affect most of them.

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

Depends on the situation as to whether it's detrimental. Proxy-aggregation,
as this is called, can alter traffic patterns in dual-homed situations. The
change is not always bad, though it is often un-desirable.

In general, proxy-aggregation is good for everybody.