[1249] in North American Network Operators' Group
Re: Sprint BGP filters in 207.x.x.x?
daemon@ATHENA.MIT.EDU (Avi Freedman)
Wed Dec 13 11:48:41 1995
From: Avi Freedman <freedman@netaxs.com>
To: cook@cookreport.com
Date: Wed, 13 Dec 1995 11:28:36 -0500 (EST)
Cc: dmbarton@mci.net, smd@chops.icp.net, nanog@merit.edu
In-Reply-To: <Pine.SUN.3.91.951213110855.11239E-100000@tigger.jvnc.net> from "Gordon Cook" at Dec 13, 95 11:17:40 am
> 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
