Sprint violations (setting space aside for slow-start allocations)
nmw at haven.ios.com
Thu Sep 21 19:19:52 UTC 1995
>>> Also, I note that we currently are not applying this list
>>> *outbound* or against customer BGP sessions. The reason for this
>>> is quite simple -- call it a (very) small incentive for other folks
>>> we peer with to apply the same kind of inbound filter against very
>>> long prefixes.
>So you are suggesting that we filter out the attached announcements
>that are behind AS1239?
If Sprint does it, why don't you do it? Anyways, that's the goal, to
make a policy standard de facto. My only objections to the /18 limit in
the 206-239 address space is that the NICs must have some pool of space
that they can use for their slow-start allocation policies.
>Or to continue with the perfectly clear translations:
>"I'm messing with your customers, so you can mess with mine."
If anyone is messing with others it's NICs that assign long prefixes
where they shouldn't. If they've run out of space for slow start
allocations, then maybe we should agree to set aside certain chunks of
space for small allocations (206.128/12 for /20s, 206.144/12 for /19s,
for example, etc..) as that would make it far easier to write short,
effective filters (and lighten the filtering load on border routers).
It can also be argued that when large providers adopt policies of the
sort that Sprint has they are trying to force an address allocation
scheme on the rest of the net. I have no problem with this so long as
this does not raise barriers to entry into the market too much; the
way to prevent this is to make sure new providers can get allocations,
which means slow-start allocation policies must be possible. It's
probably in the interest of large providers to make sure slow-start
allocation policies are possible so as to protect themselves from
anti-trust investigations that the DoJ might start.
If Sprint is not doing a good job of aggregating its announcements,
filter them, eventually they'll get around to aggregating everything
So how about agreeing on pools of address space for small allocations?
More information about the NANOG