Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt

From: [email-masked] (Noel Chiappa)
Date: Mon, 4 Mar 2013 11:05:53 -0500 (EST)

> From: Jeff Wheeler <[email-masked]>

    > LISP is a pet project. ... If you folks want it to grow out of the pet
    > project stage anytime soon, then you should stop treating it like a pet
    > project and start thinking about how to make it scale up effectively
    > ...
    > in business terms

I hear you, but Rome wasn't built in a day. Before the RIRs (for addresses),
and the registrar/registry system for DNS names, there were simpler things;
the current systems weren't brought forth full-grown, like Athena from Zeus'
brow.

    > not just in technical terms (like negative map cache entries, which are
    > a disaster)

Some of us have been trying to make sure that on the technical side, LISP has
the ability to scale to whatever scale is needed. No doubt there are still
lacks: some of which we may know about, others we probably don't. But any we
don't know about I personally would very much like to hear about. (Although
that's probably a new thread.)

But just out of curiousity, what's the issue with negative cache entries? I
haven't ever thought about them, so you may have seen something worth hearing
about.

	Noel

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 4 Mar 2013 13:13:28 -0500

> the current systems weren't brought forth full-grown, like Athena from Zeus'

Yes, and look how much more accessible the domain name system is now.

If you want LISP to flourish, then you should be thinking about how to
make it more accessible.  The community of researchers, developers,
and users LISP has today is not sufficient to solve some of its
technical problems relating to making it possible to scale up.
Increasing the community of users and businesses vested in LISP's
potential success will increase its chances of fulfilling its goals --
like making it able to scale up to become an alternative to today's
DFZ technologies.

> haven't ever thought about them, so you may have seen something worth hearing

I believe that you and I have discussed this issue on this WG list
before.  See my posts from ~2011 on negative cache entries.  It is
TRIVIAL to reduce a serious problem with negative cache entries by
90%.  Maybe my suggestion, that makes the problem order-of-magnitude
better, isn't even the best fix.  Someone else could think of a
superior solution.  As it stands, the LISP community has refused to
even acknowledge the problem exists or is worth solving.

Back to the EID block issue, imagine I'm godaddy.com and I have the
opportunity to sell numbers the way I sell letters now.  If I think I
can make money doing it, I will.  And I'll make it as easy as possible
for end-users.  I'll build a scaled-up mapping service for my
customers.  I might even fund some fellowships for researchers like
yourself to work on LISP.  I'll definitely be vested in its commercial
success, because I'll see it as a way to make money doing something
I'm already good at -- essentially selling virtual goods in a
user-friendly way.

Maybe it will be learned that for-profit companies aren't good
stewards of IP addresses.  On the other hand, some folks have pretty
serious complaints about the RIRs now, and they charge a lot of money
for their virtual goods.  They are also extremely difficult to work
with, so the barrier-to-entry is artificially high.

Given that this is a limited-time experimental block, the potential
rewards from selecting one or more private, for-profit companies to
register EID blocks seem to greatly outweigh the potential hazards.
Besides that, the hazards are a good thing.  If the worst happens
(whatever that is) then valuable things will be learned.  If it
doesn't, LISP will have more businesses supporting it and more
end-users who want it to work for them.

Dino's assertion that EID block registration must be performed at no
more than the cost of performing the service is myopic.  The service
should be provided with someone who has an interest in LISP's success,
and who has experience at performing registration services, including
authenticating companies and people.  If you allow domain registrars
to make some money by providing EID registration then they should
certainly want it to be commercially-successful.

On Mon, Mar 4, 2013 at 12:54 PM, Arturo Servin <[email-masked]> wrote:
>         I though that LISPs users would be ISPs.

If LISP succeeds in its goals then ISPs will be AMONG the users of
LISP.  There should also be branch offices, power-users, anyone who
wishes to be multi-homed, mobile, or simply to avoid ever renumbering,
ought to be interested in LISP.  That's why it needs a superior way to
scale and the reason the map caching system exists (even though it has
challenges to overcome.)  That's also why the community needs to
develop experience with low-barrier-to-entry EID allocations to small
users.

>         And honestly, I do not how a business would have a profit allocating EIDs.

How do you think godaddy profits by allocating letters?  They do it by
being efficient and user-friendly.  That is exactly what you should
want.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Mar 2013 10:30:37 -0800

+1

Dino

On Mar 4, 2013, at 8:05 AM, [email-masked] (Noel Chiappa) wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Arturo Servin <[email-masked]>
Date: Mon, 04 Mar 2013 17:58:29 -0200

Jeff.

	IMHO your assertion is wrong.

	The reason is because the economic dynamics of domain names are very
different than numeric internet resources. That is why.

/as

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 4 Mar 2013 15:09:28 -0500

> different than numeric internet resources. That is why.

Oh?  Are we running out?  If so, perhaps letting LISP use a /12 or /16
for an experiment without a clearly-defined mechanism for delegating
the address space to participants is unwise.

Without limited supply, the economics are not different at all than
domain names + green SSL certificates.  Charge money, authenticate
identity, and issue delegation.

Remember that domain names were a lot more expensive when users had no
choice but Network Solutions for .com and friends.  Now registrars are
making lots of money charging far less money, and they are providing
substantially superior service -- you don't just get a zone delegation
but also DNS service, phone support that is good, nearly-instant
turn-around, etc.

Limited supply is precisely why I suggested it is more similar to the
green SSL certificates (for larger blocks) than domain registration.
You've got to figure out if there is at least some kind of legitimate
business or person.  What you don't want is anyone who wants a
provider-independent EID block having to spend several thousand
dollars to get one, and that's if their RIR rules even allow them to
meet qualification criteria, if they can even figure out how to apply.

The economics are more similar than you realize.  The benefit to
end-users and to the LISP project are big and the cost is ... what,
exactly?

It's experimental address space.  There really isn't cost.  If it
turns out to be a mistake, valuable lessons will be learned.

---

From: David Conrad <[email-masked]>
Date: Mon, 4 Mar 2013 17:14:29 -0800

Jeff,

On Mar 4, 2013, at 10:13 AM, Jeff Wheeler <[email-masked]> wrote:
> more than the cost of performing the service is myopic.  

Just for clarification: I believe it was I that mentioned this in my strawman requirements for EID block management, not Dino.

I understand what you are saying but believe you're trying to put the cart before the horse.  As things stand now, their is little knowledge of LISP so you get into the same chicken-or-egg problem we've had with IPv6. For an experiment, I believe you need to make resources as easy to get as possible in order to minimize barriers to entry.  Every barrier, be it price or legalese or justification hoops (or even figuring out where to go to get EIDs), reduces the likelihood people will be interested in playing.  Hence my suggestion the allocation/registration service be no more than cost.

Remember that even IPv4 addresses were given away by the millions for free back in the day.  It took over a decade before user fees were required. Hopefully LISP will grow more quickly than the Internet did.

Perhaps a more interesting question is what services will the EID allocator/registry need to provide (in addition to allocating EIDs and keeping registration data).  Two services mentioned so far are:

1) whois, to lookup the registration data
2) reverse dns, so people can map EIDs into domain names

Providing these services has a cost that correlates with a committed service level (e.g., 5 9s service costs much more than 1 9s service).  What level of service is acceptable for the LISP experiment?

Regards,
-drc

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 5 Mar 2013 05:44:18 -0500

> I understand what you are saying but believe you're trying to put the cart before the horse.  As things stand now, their is little knowledge of LISP so you get into the same chicken-or-egg problem…

I don't agree that I've put the cart before the horse.  What I've
suggested is a potentially more efficient way to get EIDs to
participants, provide them with a "point-and-click" option for map
server, and the items you list below, whois and reverse DNS, without
you getting bogged down in the RIR policy process AND without trying
to make RIR memberships bear the costs associated with these services.

AFRINIC can't afford to spend money on things its members don't want.
RIPE NCC just spent a million bucks of members' money on RPKI that it
turns out a lot of people don't want, and they have now undertaken an
efficiency program to cut programs that members don't want to pay for
anymore.  ARIN estimated over $50k USD expense just to add password
authentication support to its IRR database, a service it already
provided, and then took over six months to get it done.

Expecting RIRs to be excited about this and do it effectively is
expecting a lot from organizations who range from cash-strapped to
simply inefficient, but in all cases, their policy processes are going
to take very significant time.

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.

How many people in this discussion actually deal with any RIR on a
regular basis?

> Providing these services has a cost that correlates with a committed service level (e.g., 5 9s service costs much more than 1 9s service).  What level of service is acceptable for the LISP experime…

I think you need these items to collaborate and troubleshoot problems
in a hopefully growing community of users.

Both these items are easy and inexpensive.  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.

---

From: David Conrad <[email-masked]>
Date: Tue, 5 Mar 2013 08:23:32 -0800

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.

> 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.

> 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

Has anyone characterized the anticipated operational load of mapping service (bandwidth/pps)?

Thanks,
-drc

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 5 Mar 2013 13:35:07 -0500

> 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 m…

The question at hand is who would be good / desirable to perform this role?

> There is another model where you ensure uniqueness by partitioning the space amongst the retailers, but I'm assuming you're not proposing that.

I think there are better options than partitioning the space, yes.

> 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/approp…

I don't think it matters that they can't charge a premium for
x:867:5309::.  If they felt like they had to charge a premium for
services to make money, would they be selling $9/year dot-coms or
relatively inexpensive green-SSL-certs?  They operate efficiently
enough to provide these services (plus DNS, some even email or basic
web hosting) for a low price to the end-user.  Not only that, many
registrars answer their phone 24x7, and you can almost certainly find
a domain-registrar with staff who speaks your local language and does
business in your local currency.

I wouldn't expect more than a small number of registrars to become
"early adopters" but it puts in place a time-limited, experimental
framework for what LISP needs in the long-term to be successful.  I
don't see how that can be anything other than a win, as long as at
least one registrar chooses to participate.

> 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 aggre…

If you want something "as simple as possible" you could ask one of the
academic institutions or companies who are working on LISP to do it,
hand out the EID blocks for no charge, and figure out how to scale it
up and generate revenue later.

So the truth is, you probably don't want "as simple as possible" but
you want one party to be the traffic-cop for all registrations, and
initially, probably the sole source for anyone who wants to buy an EID
block.

We disagree here because I think there is huge value to expanding
LISP's ecosystem.  Having a few for-profit companies interested in it,
besides the companies making routers, would be healthy.

[dns & whois]
> 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.

I agree that probably isn't needed, but I think it would be easier
than you suppose.

On Tue, Mar 5, 2013 at 12:42 PM, Arturo Servin <[email-masked]> wrote:
>         Having two mechanisms to allocate EID. Private and RIRs.

I'm not suggesting two different mechanisms.  I'm suggesting one
framework under which both an RIR and a private company could be
registrars.  I don't think there need be any distinction between them.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 05 Mar 2013 15:40:37 -0500

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