Sprint BGP filters in 207.x.x.x?
freedman at netaxs.com
Wed Dec 13 16:28:36 UTC 1995
> 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).
More information about the NANOG