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

[Avi Freedman <freedman () netaxs com>]

> 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).

Avi