Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
No, what it means is: "People who inject routes in the global routing table, for whatever reason, increase the cost of operating routers. So for reasons of fairness and as a mild deterrent, these people should bear a generous share of the costs associated with operating the RIR infrastructure."
Again, this implies the existence of some sort of cross-domain funds- transfers. As there is no direct and transparent relationship between ensuring uniqueness of address space blocks (RIR business) and those covering the cost of implementing the routing layer for the global Internet, it would simply be an address tax raised by the RIRs. There's not even the concept of "reverse funds" transfer from the RIRs charging for such addresses back to the LIRs.
A good way to do this would be to require everyone who wants such a block to become a RIR and to charge address based costs only on the number of blocks and not on their size.
No, see above. [btw, I assume the string "RIR" in the previous paragraph is just a typo and that you meant to type "LIR". Otherwise this would be a clever move to kill the proposal - by sending them to ICANN for recogition as an RIR :-] And, I presume that addresses would only be distributed by way of an LIR anyway. So where is the point?
Note that I'm not saying these people should pay an artificially inflated fee (although deep in my heart I would love that), just their fair share.
With your definition of fair for something you don't like :-) Scary...
It shouldn't be cheaper to obtain a special prefix than a regular one.
Indeed, and then it should not be smaller or, rather, more difficult and risky to use.
Also, there should be limits on the number of special prefixes.
Ahem, how many - and why? Wilfried.
On 24-mrt-05, at 10:31, Wilfried Woeber, UniVie/ACOnet wrote:
No, what it means is: "People who inject routes in the global routing table, for whatever reason, increase the cost of operating routers. So for reasons of fairness and as a mild deterrent, these people should bear a generous share of the costs associated with operating the RIR infrastructure."
Again, this implies the existence of some sort of cross-domain funds- transfers.
No, it explicitly states that that doesn't exist.
As there is no direct and transparent relationship between ensuring uniqueness of address space blocks (RIR business) and those covering the cost of implementing the routing layer for the global Internet,
Yes, I said that.
it would simply be an address tax raised by the RIRs.
RIR operation costs money. This money has to be recovered somehow. The only thing I'm saying is that special address holders should pay for this relative to their contribution to the global routing table. There are of course other ways to go about this, such as make the fees dependent on the amount of work the RIR has to do. But I think my suggestion is better.
A good way to do this would be to require everyone who wants such a block to become a RIR and to charge address based costs only on the number of blocks and not on their size.
No, see above.
Why wouldn't they have to become a LIR (yes, typo)?
And, I presume that addresses would only be distributed by way of an LIR anyway. So where is the point?
Today you can get v4 PI space without becoming a LIR.
Note that I'm not saying these people should pay an artificially inflated fee (although deep in my heart I would love that), just their fair share.
With your definition of fair for something you don't like :-) Scary...
I'm very fair with what I like and dislike, don't worry. :-) The thing is that routes in the routing table is like polution of the environment. We know we can't completely stop it, but it helps if there are monetary incentives so that people at least consider the alternatives. Don't forget that DNS anycasting isn't an essential technique, it's just an optimization. However, if the plus side ends up at the TLD operator and the minus side at the internet users at large, this optimization won't be very optimal.
It shouldn't be cheaper to obtain a special prefix than a regular one.
Indeed, and then it should not be smaller or, rather, more difficult and risky to use.
Nope, these attributes have nothing to do with the fees involved. Address space isn't for sale.
Also, there should be limits on the number of special prefixes.
Ahem, how many - and why?
To keep the global routing table from growing too quickly. The exact number is hard to determine, but something like 10% of the existing routing table per year seems reasonable, maybe a bit more the first few years.
Iljitsch van Beijnum wrote:
The thing is that routes in the routing table is like polution of the environment. We know we can't completely stop it, but it helps if there are monetary incentives so that people at least consider the
<drift heading=OT>In real life often enough parties "buy the right to pollute" where there is noone really in a position to sell. I wonder whether this model can succesfully be applied here.</drift>
alternatives. Don't forget that DNS anycasting isn't an essential technique, it's just an optimization. However, if the plus side ends up
If an optimization at all, it's an essential one. Reasons for DNS anycasting have been stated multiple times and rehashing them over and over again won't make any progress. Let's assume it's best practice as long as certain criteria are met.
at the TLD operator and the minus side at the internet users at large, this optimization won't be very optimal.
TLD and root servers are a prime example for an "at large" benefit, so while I'd agree with your statement, the preconditions aren't met. Is there anything in the current proposal that makes it "too easy" to get the address space? Any suggestions for rewording or clarification? -Peter
On 24-mrt-05, at 12:53, Peter Koch wrote:
alternatives. Don't forget that DNS anycasting isn't an essential technique, it's just an optimization. However, if the plus side ends up
If an optimization at all, it's an essential one.
We're talking about TLDs here, not the root. There are very few TLDs that even use the full 13 or so addresses that are possible without using EDNS0. Country code TLDs have existed for 20 years without trouble without anycast, so I really don't see why this would be necessary now, especially as the shorter RTTs that are possible with anycasting are extremely unlikely to make a noticeable real-world difference.
at the TLD operator and the minus side at the internet users at large, this optimization won't be very optimal.
TLD and root servers are a prime example for an "at large" benefit,
I'll go along with you for the root part but arguments for the root don't automatically carry over to TLDs.
Is there anything in the current proposal that makes it "too easy" to get the address space? Any suggestions for rewording or clarification?
The fact that it exists makes it easy. One thing that would help is forbid the use of more than one IPv6 prefix for a nameserver (cluster) under the same administrative and/or technical management. I.e., if .nl and .fr both want to anycast and they both hire Anycast PLC to run anycast instances around the world, they don't both get a prefix, but have to share one. Don't forget that changing addresses for a TLD server is a simple administrative procedure (= no new root.zone) so it's easy to change addresses when the situation changes. And I think one special prefix per TLD is enough.
iljitsch@muada.com (Iljitsch van Beijnum) wrote:
We're talking about TLDs here, not the root. There are very few TLDs that even use the full 13 or so addresses that are possible without using EDNS0. Country code TLDs have existed for 20 years without trouble without anycast, so I really don't see why this would be necessary now, especially as the shorter RTTs that are possible with anycasting are extremely unlikely to make a noticeable real-world difference.
I don't see from where you take the right to decide for a TLD registry how they should run their operations. There are a lot of reasons for doing one or the other, but I cannot see where you come in. Apart from that, I can tell you that these shorter RTTs make a hell of a difference. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On 24-mrt-05, at 14:05, Elmar K. Bins wrote:
I don't see from where you take the right to decide for a TLD registry how they should run their operations.
The same place they find the right to take up space in my routing table.
Apart from that, I can tell you that these shorter RTTs make a hell of a difference.
Then you're running the wrong DNS software. A good resolving server should keep track of the TTLs towards different nameservers for a zone and try to talk to the one with the lowest TTL first most of the time. From your other message:
There is, however, a difference between routing table pollution (mostly because of missing or failing aggregation) and small prefixes in the routing table due to "special" PI service blocks. One should not mix this.
It's natural to look at these differently, but the end result is invariably the same: more CPU and memory usage in the routers.
Iljitsch van Beijnum wrote:
We're talking about TLDs here, not the root. There are very few TLDs that even use the full 13 or so addresses that are possible without
it might appear so since they are already anycasting. And with IPv6 it's no longer really 13. And by the way, that's exactly covered in the proposed policy, so the applicant has to provide some reasoning.
using EDNS0. Country code TLDs have existed for 20 years without trouble without anycast, so I really don't see why this would be
Well, I've been told that some things have changed during those 20 years, including IPv6 deployment, query volume increase, DoS attacks, user expectation to name a few.
necessary now, especially as the shorter RTTs that are possible with anycasting are extremely unlikely to make a noticeable real-world difference.
They might not for a single user but they definitely do -- even more so for the users "at large".
TLD and root servers are a prime example for an "at large" benefit,
I'll go along with you for the root part but arguments for the root don't automatically carry over to TLDs.
Nothing automatic here, but just one example: most people during the day hit more SLDs in a single TLD than they hit different TLDs.
prefix for a nameserver (cluster) under the same administrative and/or technical management. I.e., if .nl and .fr both want to anycast and they both hire Anycast PLC to run anycast instances around the world, they don't both get a prefix, but have to share one.
That raises the question whether the prefix is per TLD or per DNS operator. Thanks for your input - any comments anyone else?
And I think one special prefix per TLD is enough.
Assumed the former this has interesting implications. -Peter
On 24-mrt-05, at 14:25, Peter Koch wrote:
We're talking about TLDs here, not the root. There are very few TLDs that even use the full 13 or so addresses that are possible without
it might appear so since they are already anycasting.
I was talking about addresses, not about servers. It makes no sense to anycast when there is room for more regular addresses.
using EDNS0. Country code TLDs have existed for 20 years without trouble without anycast, so I really don't see why this would be
Well, I've been told that some things have changed during those 20 years, including IPv6 deployment, query volume increase, DoS attacks, user expectation to name a few.
Yes, and these changes over 20 years could be accommodated without TLD anycasting. My point isn't that there shouldn't be any TLD anycasting, just that TLDs can get by just fine without it too.
necessary now, especially as the shorter RTTs that are possible with anycasting are extremely unlikely to make a noticeable real-world difference.
They might not for a single user but they definitely do -- even more so for the users "at large".
The users "at large" of ccTLDs are clustered within a small part of the network so having anycast instances all over the place doesn't help the users at large, only the very few that go to .nl from Argentina or some such. And since they incur longer round trips for the query to the authorative nameserver for the domain and then for the actual communciation anyway, the benefit to those users is also relatively low.
iljitsch@muada.com (Iljitsch van Beijnum) wrote:
And, I presume that addresses would only be distributed by way of an LIR anyway. So where is the point?
Today you can get v4 PI space without becoming a LIR.
I believe the reason for this is conservation. Any LIR is entitled to receiving a /20 up-front (allocation; certainly, assignments from this need to be made explicitly), so handing out PI /24s where no more space is needed looks like the better alternative. Of course, the right to the first allocation might be removed. This has not happened yet.
Ahem, how many - and why?
To keep the global routing table from growing too quickly. The exact number is hard to determine, but something like 10% of the existing routing table per year seems reasonable, maybe a bit more the first few years.
There is, however, a difference between routing table pollution (mostly because of missing or failing aggregation) and small prefixes in the routing table due to "special" PI service blocks. One should not mix this. Yours, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Hi, On Thu, Mar 24, 2005 at 02:02:31PM +0100, Elmar K. Bins wrote: [..]
I believe the reason for this is conservation. Any LIR is entitled to receiving a /20 up-front (allocation; certainly, assignments from this need to be made explicitly), so handing out PI /24s where no more space is needed looks like the better alternative.
Of course, the right to the first allocation might be removed. This has not happened yet.
Sidetracking: actually we tried that (added criteria for the first IPv4 allocation) - result? People got 'me a handful of /24 PI networks, paying some small saving on the address space side with more pollution on the routing table size. So we changed it back. Policies interact. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Sidetracking: actually we tried that (added criteria for the first IPv4 allocation) - result? People got 'me a handful of /24 PI networks, paying some small saving on the address space side with more pollution on the routing table size. So we changed it back.
When we transition to IPv6, we lose any benefits of the savings in IPv4 addresses, however, the penalty of pollution in the routing table is multiplied. Savings in IPv4 space, do not carry over into IPv6. That is why we lose these savings. But the size of the routing table increases by 4 times therefore requiring 4 times as much RAM and 4 times as much time to send/receive full routes. No doubt one could apply some weighting factors and conclude that the overall penalty is multiplied by less than 4 times, however the fact is that the penalty is greater. Therefore, is it false economy to have policies which put IPv4 address space conservation higher on the agenda than routing table size conservation? Policies interact, including interaction between IPv4 and IPv6 policy. With IPv6 we can afford to be generous. --Michael Dillon
participants (6)
-
Elmar K. Bins -
Gert Doering -
Iljitsch van Beijnum -
Michael.Dillon＠radianz.com -
Peter Koch -
Wilfried Woeber, UniVie/ACOnet