This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
- Previous message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Randy Bush
randy at psg.com
Thu Mar 24 16:22:02 CET 2005
>>>>> 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
- Previous message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]