Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
OK, so I guess my point altogether is that I dislike special-ness. There seems to be agreement that DNS anycasting is here to stay so the only point of contention is the size of the prefix. Using longer prefixes does not add much to the conservation and introduces more exceptions. Even if other RIRs are doing /48s already why would introducing an additional chunk of swamp space with the potential for more likely large scale failure be of any benefit? If people agree with assigning the addresses for this purpose, which seems to be the case, just issue a standard allocation and be done. Regarding the issue of flap damp(en)ing parameters, I think we should really revisit the flap damp(en)ing recommendations again at RIPE 50. Joao PS: regarding entries in the routing table and the pollution it causes, keep an eye on RFCs coming soon. PS: regarding the use of "wrong DNS software", the TLD operator is running *SERVERS* and providing services to resolvers/users. The best they can do is provide as good a service as they can to their consumers, not preach to them about them running the wrong client side software.
On 24-mrt-05, at 15:06, Joao Damas wrote:
Regarding the issue of flap damp(en)ing parameters, I think we should really revisit the flap damp(en)ing recommendations again at RIPE 50.
It should happen before doing anything with regard to this proposal, though. And what kind of changes do you imagine?
PS: regarding entries in the routing table and the pollution it causes, keep an eye on RFCs coming soon.
Do you have the draft names? That saves me the waiting. :-)
PS: regarding the use of "wrong DNS software", the TLD operator is running *SERVERS* and providing services to resolvers/users. The best they can do is provide as good a service as they can to their consumers, not preach to them about them running the wrong client side software.
We shouldn't go out of our way to help people who don't help themselves. Inflating the routing table because DNS software doesn't do what it should do is WRONG.
On 24 Mar, 2005, at 15:10, Iljitsch van Beijnum wrote:
On 24-mrt-05, at 15:06, Joao Damas wrote:
Regarding the issue of flap damp(en)ing parameters, I think we should really revisit the flap damp(en)ing recommendations again at RIPE 50.
It should happen before doing anything with regard to this proposal, though. And what kind of changes do you imagine?
OH, that would be for the wg to discuss, but perhaps deprecation would be amongst the possibilities that need consideration
PS: regarding entries in the routing table and the pollution it causes, keep an eye on RFCs coming soon.
Do you have the draft names? That saves me the waiting. :-)
In this case it would not, really :) You will have to be a bit patient. Joao
OK, so I guess my point altogether is that I dislike special-ness.
There seems to be agreement that DNS anycasting is here to stay
and it's special enough to require special policy. i.e. one does not have to like consistency to dislike specialness. randy
Hi Randy! On 24 Mar, 2005, at 15:26, Randy Bush wrote:
OK, so I guess my point altogether is that I dislike special-ness.
There seems to be agreement that DNS anycasting is here to stay
and it's special enough to require special policy. i.e. one does not have to like consistency to dislike specialness.
one tries to limit it to the minimum. Joao
mornin' joao,
OK, so I guess my point altogether is that I dislike special-ness. There seems to be agreement that DNS anycasting is here to stay and it's special enough to require special policy. i.e. one does not have to like consistency to dislike specialness. one tries to limit it to the minimum.
so, in this case, would that be o only tlds can get this specialness o only dns services can get this specialness o any anycasting services can get this specialness o any services which can justify address space get the space (which is what we theoretically have today)? randy
On 24 Mar, 2005, at 15:36, Randy Bush wrote:
mornin' joao,
OK, so I guess my point altogether is that I dislike special-ness. There seems to be agreement that DNS anycasting is here to stay and it's special enough to require special policy. i.e. one does not have to like consistency to dislike specialness. one tries to limit it to the minimum.
so, in this case, would that be o only tlds can get this specialness o only dns services can get this specialness o any anycasting services can get this specialness o any services which can justify address space get the space (which is what we theoretically have today)?
Dunno, you will have to ask the wg. What is your take on it? On a separate issue, your 3rd bullet point: are there any more results from your study on the routing of anycasted services? Some people are telling they are OK with using anycast for TCP and I am certainly curious. Joao
OK, so I guess my point altogether is that I dislike special-ness. There seems to be agreement that DNS anycasting is here to stay and it's special enough to require special policy. i.e. one does not have to like consistency to dislike specialness. one tries to limit it to the minimum. so, in this case, would that be o only tlds can get this specialness o only dns services can get this specialness o any anycasting services can get this specialness o any services which can justify address space get the space (which is what we theoretically have today)? Dunno, you will have to ask the wg. What is your take on it?
i am trying to understand this mess. seems to me that two points raised this morning (your daytime may vary:-) raise an interesting question. if /32 filters are to be no longer implied by allocation policy, i.e., folk should filter on /48, why can't anycasters just use a /48 out of their other v6 chunk? otoh, if we want allocation policy to imply filtering on /32 or whatever (i note the rightward creep in v4 from /19 to /21-/22), anycasters are suggesting we throw a rather large chunk of address space (79,228,162,514,264,337,593,543,950,336 hosts, i don't even know how to say it in american) at a handful of hosts. so we must think v6 space essentially infinite. but, if time has taught us anything about scaling, we've seen every hard and fast number picked in computing turn out to be insufficient in the long run. but here we don't seem to have the traditional conflict between conservation of address space and conservation of routing table, as an anycaster is gonna announce a prefix anyway. and i am not sure it is safe to assume anycasters will be few or the 'importance' of particular anycast services will show clear classes except in the minds of the folk deploying them. so i suspect that we are on a slippery slope and we have no real grasp of it's future angle or length. i suspect this is why so many of us are uneasy. it's actually a hard question and we have quite insufficient information. personally, i have no answer. sorry to make you read all this rubbish to find that. why not show a bit of wimsey and block out 42 /32 chunks for this and have a three month bidding period to see how much money the rirs can collect to donate to heal some of the horrifying wounds of the latest natural disaster or unnatural us imperialism?
On a separate issue, your 3rd bullet point: are there any more results from your study on the routing of anycasted services?
we were not really looking at anycast services per se, just using anycasted prefixes to highlight routing issues, as they seemed wont to do. we're hoping to present more come nanog time. randy
participants (3)
-
Iljitsch van Beijnum -
Joao Damas -
Randy Bush