[address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
- Previous message (by thread): [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
- Next message (by thread): [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Max Tulyev
maxtul at merezha.net
Thu Apr 20 16:45:02 CEST 2006
Hi! Please, somebody, explain me The Big Problem! How routing table size on borders really affects the Internet? But please tell me about REAL routers and REAL situation. I can't see the differense between 10 path static routing and 190000 full view BGP even on old-like-dinosaurus-bones Cisco 3660. What I am doing wrong? > Hi Pekka. Totally agree with you there. > At the moment as we have PI with IPv4, and I'll guess there will be > lot's of fuzz dropping It. > On the other hand. If PI allocations were no more, then the same people > you nag about here would try to become their own ASN:s. > And the percentage of peers running on cheap 'o pc-boxes would quite > possibly increase. > Resulting in that the problem with flapping routes would probably > remain, or even get worse. > > So the problem is really. How do we regulate PI to only be an accepted > solution for extreme cases? > And still have a fair policy to those who really needs this feature. > > > Best regards. > > --Dennis Lundström > GippNET > > Pekka Savola wrote: > > Hi, > > > > I don't support PI space to end-sites. We have to get rid of the > > notion that a random end-site has any business whatsoever in mucking > > with the global routing tables, either by making it much larger than > > need be or by polluting it with needless dynamicity. > > > > Example of the latter: deploying inbound traffic engineering > > adjustment solutions which result in thousands of daily flaps in the > > advertisements, as shown by Huston's analysis. > > > > We have way too much trouble with clueless ISPs to also add (or > > continue to add) end-sites to the mix... > > > > .... > > > > Now, from practical point of view, it seems there is strong "need" for > > PI, and it might be a PI policy of some kind might actually get through. > > > > If so, the policy should be such that it minimizes the bad effects of > > PI and encourages people to use other solutions if those are viable > > for them (unfortunately, the only way to achieve that appears to be > > $$$$), in particular (in the rough order of importance): > > > > 1. Each assignment must be accompanied by a recurring fee (at least > > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > > (compared to other costs) to anyone who actually needs this > > multihoming solution. However, this ensures at least some minimum > > usage barrier ("those who don't really need this can use different > > multihoming solutions"), and recovery of the resources back to RIR > > after the company has gone bankrupt or no longer needs the addresses. > > If you don't know where to put the extra money, donate it to ISOC or > > something. > > > > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > > don't have much preference here), but you must not be able to justify > > for larger space. This is to avoid the organization from getting a > > larger block and chopping it into smaller pieces and polluting the > > global routing table with more specifics which would get past prefix > > length filters. > > > > 3. assignments from a separate address block, set aside for PI. To > > ease strict "assignment-size only" filtering of these blocks.
- Previous message (by thread): [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
- Next message (by thread): [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]