Hi, Leo Vegoda wrote:
On 13 Jun 2007, at 12:21am, Sascha Lenz wrote:
[...]
Actually my customer wants to try to anycast streaming audio media. It seems to work in the lab, We want to deploy in the wild now.
that still sounds like an experiment for a new protocol - then follow my suggestion - get them an experiemental assignment. If it works out, suggest a policy.
That only works if the experiment is for a non-commercial service:
"Resources issued must not be used for commercial purposes during or following the conclusion of the experiment."
If the service is commercial then it could not benefit from this kind of assignment.
this is somewhat implicit with "experiment". He wrote "they want to try" - that doesn't sound like anything commercial to me, or probably i'm misguided and it is a fact that todays companies use their customers as beta-testers on a regular basis? ;-) If he'd wrote that they had a *REAL* product and they want to *SELL* it, i wouldn't have come up with the experimental pathway in the first place.
If the fees aren't a problem then the easiest way to get the address space might be to sign up as an LIR, get the minimum allocation and break it up. It's not the most elegant solution but it should work.
*purr* That's quite a customer-friendly rule-bending in my eyes - it doesn't solve the general "how to justify the size of an assignment needed for routing" issue. They only "half-way right" solution to this in my head sounds like becoming LIR and dedicating a sub-allocation of the PA space you get for Anycast announcement. This way you can seperately announce the Sub-Allocation, and have no problems justifying a routable *assignment* The actual assignment within the sub-allocation can be a /29 then or whatever you really need for the Anycast setup. ...doesn't really sound appealing for me though.
That being said, it would be nice to have a policy that didn't encourage people to do that sort of thing.
Correct. Like i pointed out, if there is a *concrete* need for that, i'm more than happy to have yet another policy on this. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================