|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Policy Statement on Address Space Allocations
Daniel Karrenberg <[email protected]> wrote: > > > "Alex.Bligh" <[email protected]> writes: > > > > You are not distinguishing (initial) allocation from announcement. > > Correct. This is because it is *only* the allocation that a regional > registry has *control* over. After that we can only have *influence*. > > > Your guarantee is worthless in the sense that it only gurantees that > > the announcements (as opposed to allocations) can be aggregated if > > each window allocation is tied to a single AS, > > I wouldn't call that worthless exactly, because the method has > shown some successes. > > > and thus, for instance that > > none of the allocation is for PI space > > I do not care about PI space. Those wanting it have had ample warning. Neither do I. > > or for allocation to customers > > who aren't local-IRs but have their own AS etc. etc. > > There you are! Cases of genuine need for a seperate announcement > (multihomed) are not covered by the guarantee. But my expectation > is that their number can be offset by bigger aggregates. > Note that the number of routes *currently* announced under 193/8 and > 194/8, which have some room for improvement, is quite low already. > Actually they are both within the theoretical limit of a /18 filter > which is 2047 routes. > > > You also have the problem > > that currently it is impossible for local-IRs to allocate blocks > > of IP numbers that wouldn't be filtered out to multihomed customers > > (with their own AS - thus almost inevitably requiring a separate > > announcement) where that customer under the RIPE rules isn't 'justified' > > in getting a /19 (too small, for instance). Conservation vs. aggregation > > again. What is your recommendation on this? > > I fully agree that this is a problem. I believe that the only > real solution to this is to reduce *unneeded* announcements as much > as possible. This needs a routing registry and tools. OK, point taken. But AFAIK RIPE *still* works against this goal by giving only one window. Case in point: Our current window is /19, and all our announcements are maximally aggregated. Jo Customer comes along to me and says 'I want to go multihomed with you as a second provider, currently I have 8 class C's but they are all spread about the place'. Me 'You need to renumber then esp. as your class C's are within your current providers aggregate announcments (even though they are old, and thus technically PI' (there, that's me doing my bit for aggregation). Them: 'OK, give us a /21 to renumber into, you are a local-IR and we aren't'. Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've said it, that's the minimum size allocation) which actually solves their problem and mine, but this isn't an option currently available because currently it's one window per local-IR. So they have to go and become a local IR. > This is why pure prefix length filtering is the wrong soloution. > It just favours the big providers. Yup, I'd agree with us. And I hope Sprint have had a long chat with their lawyers over there as some of the more litigious smaller US providers are busy thumbing through the anti-trust laws, apparently. > ... > > This bartering does not solve the general problem and does not > claim to. It is just part of the effort to keep things working. Yup. Alex Bligh Xara Networks.
|