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? Or to continue with the perfectly clear translations: "I'm messing with your customers, so you can mess with mine." -mark 206.15.224.0/23 206.24.100.0 206.40.96.0 206.40.97.0 206.40.98.0 206.40.99.0 206.41.128.0/20 206.41.192.0/19 206.43.48.0/20 206.43.128.0/19 206.47.2.0 206.47.3.0 206.47.4.0 206.47.12.0 206.47.14.0 206.47.17.0 206.47.18.0 206.47.19.0 206.47.20.0 206.47.21.0 206.47.22.0 206.47.40.0 206.47.41.0 206.47.42.0 206.47.43.0 206.47.45.0 206.47.46.0 206.47.47.0 206.47.80.0 206.47.81.0 206.47.84.0 206.47.85.0 206.47.87.0 206.47.88.0 206.47.89.0 206.47.93.0 206.47.94.0 206.47.95.0 206.47.96.0 206.47.104.0 206.47.106.0 206.48.57.0 206.48.58.0 206.48.59.0 206.48.60.0 206.48.73.0 206.48.112.0/21 206.48.120.0/21 206.48.128.0/19 206.53.96.0/21 206.55.64.0/22 206.56.254.0 206.64.100.0 206.71.32.0/20 206.72.64.0/22 206.80.32.0/19 206.80.64.0 206.80.65.0 206.80.66.0 206.80.67.0 206.80.68.0 206.80.69.0 206.80.70.0 206.80.71.0 206.82.160.0/22 206.108.252.0 206.108.253.0 206.108.254.0 206.194.192.0 206.195.32.0/19 206.195.64.0 206.196.96.0/19 206.197.104.0 206.197.121.0 206.197.130.0 206.197.138.0 206.197.190.0 206.197.207.0 206.201.208.0/20 206.206.0.0 206.215.224.0/19
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 they can.
-mark
So how about agreeing on pools of address space for small allocations? Nick
participants (2)
-
Mark Kent -
Nick Williams