Oe reason I like the registry/registrar architectural model fo EID
allocation is that it avoids end-site lockin with someone who might
raise their annual maintenance fees.
That does not mean it has to be done by the same folks who do RNS today.
Although they certainly should be allowed to do so if they want.
Having said that, I take David's pont that we need something simple we
can put in place now.
Is there a way to structure things with unified, automated, assignment
now, but the ability to split along this and other dimensions later?
(We don't even need to spell out the split, just be confident we can do
it if we want to.)
Yours,
Joel
On 3/5/2013 11:23 AM, David Conrad wrote:
Jeff,
You and I appear to agree that the RIRs are undesirable for the purposes of EID
management during (at least) the initial phases of the LISP experimental
deployment, so I'll skip that part of your message.
On Mar 5, 2013, at 2:44 AM, Jeff Wheeler <[email protected]> wrote:
If you permit domain registrars to offer this service, some of them
probably will, and they are able to do it more quickly and
cost-effectively than the RIRs.
While you haven't said so explicitly, I gather you're talking about a
registry/registrar split for EID allocation where you have a single entity
acting as a wholesaler that ensures uniqueness and multiple competitive
entities acting as retailers (whether the registry is 'thin' or 'thick' isn't
relevant for this discussion). There is another model where you ensure
uniqueness by partitioning the space amongst the retailers, but I'm assuming
you're not proposing that.
While the registry/registrar split model isn't without its problems (just hang
around ICANN for a while and those problems will become painfully apparent), I
would agree it might be a viable/appropriate model _in the long term_. Having
nearly daily interactions with the DNS registries and registrars at a policy
level, I have quite a bit of skepticism that they'll be at all interested in
participating in the LISP experiment at this point in time, particularly as
they're gearing up for new gTLD deployment and it is a bit unlikely there will
be much money in LISP EID allocation for the foreseeable future (if ever: it's
unlikely you'll be able to charge a premium price for particular LISP EIDs).
In the near term, I believe we want something as simple as possible. This
implies to me that a highly-automated unified registry/registrar is the right
way to go. Since EIDs do not need to be aggregatable, allocation of fixed sized
blocks more-or-less on demand (very much like Private Enterprise Numbers
allocated by IANA at http://pen.iana.org/pen/PenApplication.page) would seem to
be sufficient.
I would not have a problem with ensuring that the unified registry/registrar
system support external registrars (perhaps via EPP), thereby allowing folks
like the DNS registrars to start selling EIDs if they want. I just don't think
we should assume there are going to be folks who want to do this out of the
starting gate.
1) whois, to lookup the registration data
2) reverse dns, so people can map EIDs into domain names
I think you need these items to collaborate and troubleshoot problems
in a hopefully growing community of users.
I agree.
Both these items are easy and inexpensive.
I'd argue providing 5 9s of pretty much anything is neither easy nor
inexpensive, however at this stage of LISP deployment, I doubt 5 9s is required.
It's more challenging to
provide a mapping server because that is a service / technology they
are not familiar with, but that should also be relatively easy
compared to the policy process.
Has anyone characterized the anticipated operational load of mapping service
(bandwidth/pps)?
Thanks,
-drc
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
