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

From: Arturo Servin <[email-masked]>
Date: Fri, 01 Mar 2013 21:55:26 +0800

<rir hat off>

I think that going forward withou considering the RIR system would be a
big mistake (by either ignoring them, or doing something without asking)

I haven't read the draft carefully (I will) but I think that if the
authors' intention is to promote a dialogue, it is in good direction.

</rir hat off>

Regards,
as

On 28/02/2013 03:52, Roger Jørgensen wrote:
> On Wed, Feb 27, 2013 at 8:44 PM, Joel M. Halpern <[email-masked]> wrote:
>> That similar.  My point is specifically to stay out fo "who" except for the
>> root.
> 
> excellent, think we can agree on that really, and that's one direction to think.
> 
> I would really like to hear if any other have other possible direction
> we can consider, either with or without existing RIR system.
> 
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 01 Mar 2013 12:03:08 -0500

Could you please explain why you beieve it is important to consider the 
RIRs?  It is quite possible I am missing something.

As a participant, I believe I have said clearly that I prefer that we 
spell out what our allocation / delegation / application behavioral 
requiremens are, without specifying who would meet them.

My expectation is that this would result in something where there RIRs 
could participate, and where non-RIRs could also participate withot 
going through the RIRs.

Yours,
Joel

On 3/1/2013 8:55 AM, Arturo Servin wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 02 Mar 2013 01:38:01 -0500

(Speaking personally, and interested in more data or perspectives.)

As far as I can tell, EID space is not Internet routable IPv6 Unicast space.
And the coordination requirements appear to me to be quite different 
from those for IPv6 routable unicast addressing.
As are the constraints which drive allocation.

Which is why I want to spell out the requirements, rather than writing 
in who will fill those requirements.

Yours,
Joel

On 3/2/2013 1:31 AM, Arturo Servin wrote:
>
> 	Because the draft is about IPv6 unicast space. Currently that is
> managed to the RIRs and IANA which seems to work well, not perfect.
>
> 	So far, no body has given an alternative to manage that space besides a
> collaboration among the RIRs as in this one.
>
> 	If you have an alernative I would love to hear it, but not just say
> that you do not want to go into the RIR system without a feasible
> alternative.
>
> Best regards,
> as
>
> P.D. Same as previus, rir hat off
>
> On 01/03/2013 17:03, Joel M. Halpern wrote:

---

From: SM <[email-masked]>
Date: Sat, 02 Mar 2013 00:07:50 -0800

>As far as I can tell, EID space is not Internet routable IPv6 Unicast space.

Arturo mentioned "IPv6 unicast space".

>Which is why I want to spell out the requirements, rather than 
>writing in who will fill those requirements.

The ITU would be more than happy to fill the requirements. :-)

This working group is going to annoy the RIRs.  They will object 
during the Last Call.  They will send a letter to the IAB.  The IAB 
will have a talk with the IESG about the birds and the bees.

Regards,
-sm

---

From: Arturo Servin <[email-masked]>
Date: Sat, 2 Mar 2013 09:21:02 +0000

On Sat, Mar 2, 2013 at 8:07 AM, SM <[email-masked]> wrote:

>  Which is why I want to spell out the requirements, rather than writing in
>> who will fill those requirements.
>>
>

Just like ENUM. Where is it by the way?  :)

>
> This working group is going to annoy the RIRs.  They will object during
> the Last Call.  They will send a letter to the IAB.  The IAB will have a
> talk with the IESG about the birds and the bees.
>

If as IETF we plain ignore them or we put administrative burdens over them
that may be a very plausible outcome. However if we work together we could
find a common approach acceptable for everyone.

> -sm

/as

---

From: Arturo Servin <[email-masked]>
Date: Sat, 2 Mar 2013 09:27:41 +0000

> As far as I can tell, EID space is not Internet routable IPv6 Unicast

Yes, that is ok, but does it have the same constraints of registration and
conservation?

Is anybody able to use the whole /16

a piece of it, a /20, /32, /48?

It has to be unique?

Do we need to register it?

If so, do we need a whois/restwhois?

reverse dns?

who is going to operate those services?

> And the coordination requirements appear to me to be quite different from
> those for IPv6 routable unicast addressing.

which are?

> who will fill those requirements.

I am ok with it. I was on the assumption that the WG have a clear idea of
those requirements already.

> Joel

Regards
as

---

From: SM <[email-masked]>
Date: Sat, 02 Mar 2013 02:17:51 -0800

Hi Arturo,
>Just like ENUM. Where is it by the way?  :)

It never took off. :-)

Regards,
-sm

---

From: Scott Brim <[email-masked]>
Date: Sat, 2 Mar 2013 11:43:38 -0500

> As are the constraints which drive allocation.

EID space is not globally routed (or routable, which is different) but
it is globally allocated, so you need some structure to manage
allocation, including universally agreed on policies for initial
allocations, further allocations, revocation, and more.  Is there a
better organization than the RIRs for all that?  The activities around
routing are derivative from the fundamental reasons for the RIRs'
existence.  "Regional Internet Registries (RIRs) are nonprofit
corporations that administer and register Internet Protocol (IP) address
space and Autonomous System (AS) numbers within a defined region. RIRs
also work together on joint projects."

Scott

---

From: David Conrad <[email-masked]>
Date: Sat, 2 Mar 2013 11:19:09 -0800

Scott,

On Mar 2, 2013, at 8:43 AM, Scott Brim <[email-masked]> wrote:
> better organization than the RIRs for all that?  

Yes. 

EIDs are globally allocated, why would you want to regionalize them?

> The activities around

The RIRs are relatively heavyweight and increasingly political structures that among other things, spend a lot of time trying to ensure the address space they allocate can be routed.  In the case of EIDs where routability is not an issue, most of the policies and processes by which the RIRs provide their services do not apply.  For example, IPv6 addresses are (at least in theory) allocated sparsely via a binary split-type algorithm to facilitate growth of blocks while limiting the number of prefixes allocated.  With EIDs, you don't have to care about that. Another example: the policies for address allocation varies per region and there are quite elaborate mechanisms in each region by which those policies are created and modified.  All of that overhead would presumably be unnecessary with EIDs.  Further, having different policies for EID allocation based on arbitrary geopolitical lines probably makes even less sense for EIDs than it does for IPv6 addresses.

I suspect a better model for EIDs would be a simple, mostly automated service, similar (not identical) to PEN/OID allocation done by IANA (http://pen.iana.org/pen/PenApplication.page).

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Sat, 2 Mar 2013 11:47:56 -0800

Arturo,

On Mar 2, 2013, at 1:27 AM, Arturo Servin <[email-masked]> wrote:
> Yes, that is ok, but does it have the same constraints of registration and conservation?

Registration: yes.
Conservation: maybe, but likely in the same way IEEE MAC prefixes need to be conserved.

> a piece of it, a /20, /32, /48?

It doesn't have to be contiguous.

> It has to be unique?

Obviously.

Yes.

Yes.

> reverse dns?

Maybe -- it isn't clear to me that reverse DNS has much of a future, regardless of EIDs.

> who is going to operate those services? 

Yet to be determined.  I suspect once the set of services that need to be provided are established, the IETF could either throw it to IANA to figure out how the services will be provided or could do an RFP like they did with the RFC editor.  As mentioned in my note to Scott, IANA already provides a somewhat similar service in the allocation of PENs.

Can you think of any reason why there should be different allocation policies for EIDs based on where you live?

> And the coordination requirements appear to me to be quite different from those for IPv6 routable unicast addressing.

EIDs can be a flat namespace. This is fundamentally different than how locators must be allocated.

Regards,
-drc

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 2 Mar 2013 12:03:36 -0800

Great post. Everyone should read carefully what David said. This doesn't have to be so hard for EIDs. And the RIRs can still keep their jobs and CAN STILL ADD VALUE.

Dino

---

From: Arturo Servin <[email-masked]>
Date: Sat, 02 Mar 2013 06:31:06 +0000

Best regards,
as

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 2 Mar 2013 12:09:00 -0800

How about this as an alternative:

(1) RIRs allocate EID space as they do PI space today.
(2) RIRs should not couple routing with allocation so they should not care about EID space advertisement in the core or in the mapping database (unless they are providing a mapping database service, which I suggest).
(3) Data-plane providers decide where they provision PITRs and decide what coarseness of EID space they advertise.

Dino

---

From: Arturo Servin <[email-masked]>
Date: Sat, 02 Mar 2013 20:12:14 +0000

David,

	After reading your email it is clear to me that the IETF should
consider to work with the RIRs instead or going around them.

	It will save us all time and effort.

	And responding your question:
> Can you think of any reason why there should be different allocation
> policies for EIDs based on where you live?

 I do not think any technical reason. But as ISP I would prefer to deal
with an RIR rather to IANA or to a new entity.

Regards,
as

On 02/03/2013 19:47, David Conrad wrote:
> Arturo,
> 
> On Mar 2, 2013, at 1:27 AM, Arturo Servin <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
> Yet to be determined.  I suspect once the set of services that need to
> be provided are established, the IETF could either throw it to IANA to
> figure out how the services will be provided or could do an RFP like
> they did with the RFC editor.  As mentioned in my note to Scott, IANA
> already provides a somewhat similar service in the allocation of PENs.
> 
>> Can you think of any reason why there should be different allocation
>> policies for EIDs based on where you live?

> 
>>     And the coordination requirements appear to me to be quite
>>     different from those for IPv6 routable unicast addressing.

---

From: David Conrad <[email-masked]>
Date: Sat, 2 Mar 2013 12:24:15 -0800

Dino,

I personally don't believe you want to open the EID space up to the policy regime associated with PI space.  There does not appear to be any technical justification to do so and the political baggage you'd be inserting EIDs into does not appear worth the cost.  

Do you really want 5 different sets of policies constraining how EIDs are allocated? Does it make any sense for a multi-national corporation to have to go to multiple organizations to get EIDs because RIR policies require use of resources exclusively in region?  Is it really necessary to go to up to 5 different Whois servers to figure out who an EID is registered to? (I could go on but I'll stop now :)).

Simply: I believe you want a single global policy under which EIDs are allocated. That's not how the RIRs work.

If (for whatever reason) folks do not feel IANA is the right place to allocate EIDs, I might suggest pushing this onto the IAOC (or whichever acronym is appropriate -- maybe in an IANA considerations section?) to do an RFP and allow the RIRs (and whoever else might want) to bid on a contract for providing global EID allocation and registration services.

However, I believe this is putting the cart in front of the horse -- the first step should be figuring out what the services are that need to be provided.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Sat, 2 Mar 2013 12:37:02 -0800

Arturo,

> consider to work with the RIRs instead or going around them.

It isn't "going around" the RIRs. I'm not assuming the RIRs are in the path to begin with.

Under which policies would the RIRs allocate EIDs? 

Wouldn't acceptance of EID allocation/registration services require the initiation of an open policy development process since EID allocation/registration services would be a _new_ service offered by the RIRs? Has that open policy development process been proposed in any of the RIRs yet?

Do the memberships of the RIRs think that RIR staff should be spending their membership fees to provide EID allocation/registration services?

> with an RIR rather to IANA or to a new entity.

ISPs would be getting locators, not EIDs.

Regards,
-drc

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 2 Mar 2013 21:40:50 +0100

Arturo,

We have no intention of going just around the RIR system. We are now
just looking at the EID-space case with an open mind.

_who_ should exercise the service are not on the table yet. First we
need to know what we need. It would be rather backwards to start a
discussion with the RIR on the EID-space when we not yet know all the
requirements for such a service/system?

David mention one difference between so-called PI space and EID-space,
PI-space are supposed to be globally routable. That's not really in
the nature of EID-space. There are probably quite alot more we need to
think through first.

--- Roger J ---

>         It will save us all time and effort.
<snip>

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: SM <[email-masked]>
Date: Sat, 02 Mar 2013 12:56:45 -0800

Hi David,
At 12:24 02-03-2013, David Conrad wrote:
>If (for whatever reason) folks do not feel IANA is the right place 
>to allocate EIDs, I might suggest pushing this onto the IAOC (or 
>whichever acronym is appropriate -- maybe in an IANA considerations 
>section?) to do an RFP and allow the RIRs (and whoever else might 
>want) to bid on a contract for providing global EID allocation and 
>registration services.

These implementation details are better left to IANA as all this is 
not part of IETF administration.  The PEN idea is interesting.

Regards,
-sm

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 2 Mar 2013 13:13:49 -0800

> Dino,
> 
> I personally don't believe you want to open the EID space up to the policy regime associated with PI space.  

Hey, if it can be simpler than the PI policy regime, then by all means. I just didn't want people to think that LISP EIDs needed *more* process/policy.

> There does not appear to be any technical justification to do so and the political baggage you'd be inserting EIDs into does not appear worth the cost.  

Well I will yield to you on such things.

> Do you really want 5 different sets of policies constraining how EIDs are allocated? Does it make any sense for a multi-national corporation to have to go to multiple organizations to get EIDs beca…

This is exactly the reason we protocol designer need help from you allocator types.

If the process gets too complicated, people will get their addresses the way they do today and can and will use them by EIDs. How a corporation advertises its EID-prefixes (via BGP route advertisement or Mapping Database registration) will be their decision.

> Simply: I believe you want a single global policy under which EIDs are allocated. That's not how the RIRs work.

Yes, that would be best IMO, and simple.

> If (for whatever reason) folks do not feel IANA is the right place to allocate EIDs, I might suggest pushing this onto the IAOC (or whichever acronym is appropriate -- maybe in an IANA consideratio…

Who do you think should allocate them? If we want minimal policy and just need a well known prefix, why can't IANA just allocate a /16 for the 10 years that Luigi indicated in the draft?

> However, I believe this is putting the cart in front of the horse -- the first step should be figuring out what the services are that need to be provided.

Would you agree to this:

(1) IANA allocates a /16.
(2) Divides up equally to RIRs.
(3) When RIRs get requests from corporations, they give them /64s (I won't argue if it is /48, /56, or /64), leaving some holes so subsequent requests can be best fit to the same corporation.

Is that too simplistic? And if so, why can't it be.

Dino

---

From: David Conrad <[email-masked]>
Date: Sat, 2 Mar 2013 14:17:08 -0800

Dino,

On Mar 2, 2013, at 1:13 PM, Dino Farinacci <[email-masked]> wrote:
> Who do you think should allocate them?

Without knowing all the management requirements and services necessary to meet those requirements, it is challenging to say. 

> If we want minimal policy and just need a well known prefix, why can't IANA just allocate a /16 for the 10 years that Luigi indicated in the draft?

One issue I have with the draft is that it appears to start out with "use the RIRs" without considering the implications of using the RIRs or even defining what the RIRs are supposed to do or the limitations on how they will do it.

I'd argue the first step would be to define the "minimal policy" to be, e.g.:

- allocations MUST be globally unique
- requirements for allocation MUST be the same globally, no regional/national/local variation
- allocations MUST be <size or way to determine size>
- allocation service MUST be provided at no more than cost
- registration data MUST be maintained and be made publicly available via <something, e.g., whois> 
- registration maintenance MUST be provided at no more than cost
- reverse dns SHOULD be provided
- the service MUST be available <service level commitments>
- etc.

Once you define the minimal policy, I personally believe the right answer would be to leave it to IANA to figure out how the service which meets that policy should be provided but that's an implementation decision. I don't think the bodies by which service is provided should be defined in the document.

> (1) IANA allocates a /16.

Not an issue (well, at least for me).

> (2) Divides up equally to RIRs.

Why? What benefit does this provide?  Is it (e.g.) a policy goal for EIDs to have different allocation requirements based on geo-political location of requester?

Having _an_ RIR provide allocation and/or registration services might make sense since it already has at least some of the infrastructure to provide those services but this makes the assumption that the RIR's membership thinks this is something the membership fees should pay for.

> (3) When RIRs get requests from corporations, they give them /64s (I won't argue if it is /48, /56, or /64), leaving some holes so subsequent requests can be best fit to the same corporation.

(skipping over a discussion on the need to have contiguous blocks of EIDs for the same corporation)

The vast majority of corporations (excluding ISPs) don't know (and probably don't want to know) the RIRs exist. I also doubt they want to get into the whole RIR membership/political world. By putting EIDs in the RIRs, you're forcing those corporations to (a) figure out which RIR they "belong" to, (b) pay RIR fees, (c) potentially (almost certainly in the ARIN region: look what happened with RPKI) enter into Registration Service or other legal agreements, etc. 

I strongly suspect that particularly for an experimental service, you want a single point of entry into something as simple, low cost, and lightweight as possible, e.g., something like http://www.sixxs.net/tools/grh/ula/list/ or IANA's PEN allocation/registration service. However, as mentioned, without knowing the requirements, it's hard to say for certain.

> Is that too simplistic? And if so, why can't it be.

The RIRs aren't simple.

Regards,
-drc

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 3 Mar 2013 12:24:18 -0800

> Without knowing all the management requirements and services necessary to meet those requirements, it is challenging to say. 

Well my steps below cod be taken as requirements. 

> One issue I have with the draft is that it appears to start out with "use the RIRs" without considering the implications of using the RIRs or even defining what the RIRs are supposed to do or the l…

I believe the intent was to just have an allocation entity so EID-prefixes could be allocated uniquely. And the RIRs were chosen because they exist and already do that function. If we all agree they are the wrong entires then we can come up with a newer model. 

> - allocations MUST be globally unique

Yes - a strong requirement. 

> - requirements for allocation MUST be the same globally, no regional/national/local variation

I won't disagree. But if we say the EID-prefixes are globally unique then how could they be different. There is no provider variable here to complicate matters. 
 
> - allocations MUST be <size or way to determine size>

Agree. 

> - registration data MUST be maintained and be made publicly available via <something, e.g., whois> 

Agree in that. But you shouldn't dictate a cost though. Some may want to bundle allocation with something else so their costs could be more but they cover with different revenue sources. 

> - registration maintenance MUST be provided at no more than cost

If you are talking about Mapping Database registration? If so, they should beefy out since that is an independent service. 

> - the service MUST be available <service level commitments>

I view EID assignment as a one-time transaction and not a continual service. 

DNS, mapping database services happen else where. We want the end-sites to have independent (and asynchronous) relationships with all these entires so they can change any without having a dependency graph to change the contingents. 

Here are the entires:

(1) Data-plane service provider (an ISP). 
(2) Control-plane Mapping Service Provider (MSP). 
(3) A one-time transaction EID-prefix allocator. 
(4) A DNS service provider. 

The only one above we don't have in wide-scale deployment today is (2). 

> - etc.
> 
> Once you define the minimal policy, I personally believe the right answer

From our email exchanges thus far, do you think we have?

> would be to leave it to IANA to figure out how the service which meets that policy should be provided but that's an implementation decision. I don't think the bodies by which service is provided should be defined in the document.

That is a very reasonable comment IMO. 

> Why? What benefit does this provide?  Is it (e.g.) a policy goal for EIDs to have different allocation requirements based on geo-political location of requester?

No - no geo-political requirement. So we could have the IANA do all allocations. 

> The vast majority of corporations (excluding ISPs) don't know (and probably don't want to know) the RIRs exist. I also doubt they want to get into the whole RIR membership/political world. By putti…

Okay - fine David. We are not forcing this and the draft could be changed. 

You are making a point, I think, by putting this EID allocation requirement into the existing RIR structure is more complicated then doing it a different way, I think people on this list are all ears. 

> I strongly suspect that particularly for an experimental service, you want a single point of entry into something as simple, low cost, and lightweight as

100% agree. So you are saying dont   use the RIRs. 

Please let me know if I misinterpreted any of your points. 

I am trying to make some conclusions. 

> possible, e.g., something like http://www.sixxs.net/tools/grh/ula/list/

Yes - I believe that is all that is needed for EID-prefix allocation. 

> or IANA's PEN allocation/registration service. However, as mentioned, without knowing the requirements, it's hard to say for certain.
> 

This email thread has already proven that in my mind. :-)

> -drc

Thanks,
Dino

---

From: David Conrad <[email-masked]>
Date: Sun, 3 Mar 2013 19:04:38 -0800

Dino,

> I won't disagree. But if we say the EID-prefixes are globally unique then how could they be different. There is no provider variable here to complicate matters. 

Currently the rules by which you obtain provider independent IP addresses (v4 or v6) differ depending on the RIR region (that is, geo-political location) in which you reside.  That is, if you live in (say) Boliva, the required information you must supply to LACNIC and other requirements you must meet in order to justify an allocation differ than that the info you must provide to APNIC if you live in (say) Japan.

At this point in LISP development/deployment, I would assume you'd want the rules by which you can get an EID allocation to be the same regardless of where you live and for the requirements to be as minimal as possible (e.g., "I'm Dino and I want an EID").

> Agree in that. But you shouldn't dictate a cost though. Some may want to bundle allocation with something else so their costs could be more but they cover with different revenue sources. 

I agree that costs shouldn't be dictated. More specifically, I don't think the draft should get into how the service is funded other than to say the allocation service can't charge more than the cost to provide the service.

> If you are talking about Mapping Database registration?

No. I was talking about a the data that would be made available via a Whois service, i.e., how does someone on the Internet find out the contact info for who 'owns' an EID.

> I view EID assignment as a one-time transaction and not a continual service. 

EID allocation is a one-time service, but to meet requirements like global uniqueness and providing registration data via Whois (or whatever), somebody has to maintain a database and a DNS server (if rDNS is used) which is a continual service subject to a service level commitment.

> (4) A DNS service provider. 
(5) A registration data maintenance service.

> From our email exchanges thus far, do you think we have?

Outstanding questions I see:

- Size of allocation?
- Confirmation that there should be no regional/national/local variation on allocation policy?
- Should Reverse DNS be implemented?
- What kind of Whois service (port 43, restful, something else)?

> No - no geo-political requirement. So we could have the IANA do all allocations. 

ICANN, as the provider of IANA functions according to RFC 2860, might be one option, particularly as this is experimental, however here there may be some dragons and pragmatic constraints that might not make them the best. I guess I'd probably put something in the IANA considerations section saying something like:

"There is an operational requirement for an EID allocation service that ensures EIDs allocated according to the requirements previously described are unique. In addition, there is an operational requirement for EID registration service that allows a lookup of the contact information of the entity to which the EID was allocated given only that EID. IANA must ensure both of these services are provided in a globally uniform fashion for the duration of the experiment."

Or something like that (that's probably not the right wording but hopefully you get the idea). I imagine there are a number of folks who IANA could ask to provide the service if they don't want to or can't do it themselves.

Regards,
-drc

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 3 Mar 2013 19:59:31 -0800

> At this point in LISP development/deployment, I would assume you'd want the rules by which you can get an EID allocation to be the same regardless of where you live and for the requirements to be a…

Yes that's correct. But I am not sure in later changes we'll need anything different but ill wait for experience to tell us that. 

Agree. 

> No. I was talking about a the data that would be made available via a Whois service, i.e., how does someone on the Internet find out the contact info for who 'owns' an EID.

Okay. 

> EID allocation is a one-time service, but to meet requirements like global uniqueness and providing registration data via Whois (or whatever), somebody has to maintain a database and a DNS server (…

Right - understand you now. 

> (5) A registration data maintenance service.

Ack. 

> - What kind of Whois service (port 43, restful, something else)?

I hope Luigi is taking note. All points are reasonable I think. 

> "There is an operational requirement for an EID allocation service that ensures EIDs allocated according to the requirements previously described are unique. In addition, there is an operational re…

Makes sense to me. 

> Or something like that (that's probably not the right wording but hopefully you get the idea). I imagine there are a number of folks who IANA could ask to provide the service if they don't want to…

Maybe someone from ICANN can respond. 

Dino

---

From: SM <[email-masked]>
Date: Mon, 04 Mar 2013 01:31:08 -0800

Hi David,
At 19:04 03-03-2013, David Conrad wrote:
>I agree that costs shouldn't be dictated. More specifically, I don't 
>think the draft should get into how the service is funded other than 
>to say the allocation service can't charge more than the cost to 
>provide the service.

The draft is getting into funding by saying that.  I don't know what 
will happen to the above.  There has been what I could describe as, 
technically, violations of what's written in some old 
documents.  Sorry, I cannot provide any details.

>EID allocation is a one-time service, but to meet requirements like 
>global uniqueness and providing registration data via Whois (or 
>whatever), somebody has to maintain a database and a DNS server (if 
>rDNS is used) which is a continual service subject to a service 
>level commitment.

BTW, reverse DNS can be useful for operational purposes.  I don't 
have an opinion about whether reverse DNS is required.

Regards,
-sm

---

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

> I agree that costs shouldn't be dictated. More specifically, I don't think the draft should get into how the service is funded other than to say the allocation service can't charge more than the co…

Do you know if any RIRs want to provide registration service for LISP
EID space?  Have you asked any RIR for a cost estimate?

As you may know, my opinion is the LISP mapping service is far from
ready for Internet-scale use.

It would require RIR policy proposal to cause them to begin allocating
address space for LISP.  The RIRs may guess how much money they would
spend on doing it, and you would be amazed how much time and money the
RIRs can spend on something that seems to be simple (and probably
should be.)

I think many members would be inclined to vote AGAINST spending
resources on LISP registration services at this time.

You might also find that for-profit entities could actually provide
service cheaper than the non-profit RIRs.  If ARIN was the sole source
of domain names, I am sure they would cost a bit more than
godaddy.com.

I believe the community thinking in this area is seriously flawed.
With respect to registration costs, your goal should be that it is
inexpensive, not that it is forbidden to make a profit from providing
the service.

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

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 4 Mar 2013 11:15:35 +0100

> resources on LISP registration services at this time.

You just mention my biggest problem with using the RIR system as it
is - policy proposal.

As said earlier, this draft mention RIR because that's a starting point, it goes
back to the suggestion I gave on draft-lisp-eid-block-03 [1*]
We could have written more in the draft on how we should do this but I think
both you and David Conrad has mention plenty of reason why we should
consider our options way before we go into the question of who should
do the job involved.
If you read my suggestion close you'll see I suggested the RIR as _one_
option.

[1*] http://www.ietf.org/mail-archive/web/lisp/current/msg04155.html

--

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 4 Mar 2013 05:56:17 -0500

> If you read my suggestion close you'll see I suggested the RIR as _one_

I read it.  I think your suggestion is pie-in-the-sky until a couple
of RIRs produce projections of the cost.

---

From: Arturo Servin <[email-masked]>
Date: Mon, 04 Mar 2013 09:02:11 -0200

To be honest, RIRs policy proposals process in the end do not look too
much different than RFCs. It is just another part of the Internet.

	This document is not just technical, it also covers matters of resource
allocation, in this case numbers. In that sense I see a value to inspect
current mechanisms in the Internet to do that task  (and make them work)
instead off reinventing the wheel.

	Also, who is going to use these resources (locators)?

	Have you asked them how they want to get them?

Regards,
as

---

From: Arturo Servin <[email-masked]>
Date: Mon, 04 Mar 2013 09:09:10 -0200

I never meant to say that the draft or the WG (I suppose that is the
"we) were around the RIRs.

	I meant that it wouldn't be a good idea to ignoring them or adding
tasks without consulting them. I see some drawbacks in using the RIRs (I
know them, I work for one) yes, but I see more in not even going to see
if they may be a good solution.

Regards,
as

---

From: Arturo Servin <[email-masked]>
Date: Mon, 04 Mar 2013 09:22:07 -0200

> Under which policies would the RIRs allocate EIDs? 

	A new policy would be needed.

> 
> Wouldn't acceptance of EID allocation/registration services require the initiation of an open policy development process since EID allocation/registration services would be a _new_ service offered by the RIRs? 

	Possibly, but, would it be very different than when RIRs started
allocating IPv6?

Has that open policy development process been proposed in any of the
RIRs yet?

	No, but if somebody could just start asking in the RIRs PDP if this
could be a good idea or not.

	If LISP has value for the community it may be not very hardto get a policy.

> Do the memberships of the RIRs think that RIR staff should be spending their membership fees to provide EID allocation/registration services?
	IPv6 was free of allocation fees for many years, I do not see why EIDs
could be different, but again, we need to ask.

> ISPs would be getting locators, not EIDs.

	ASNs are different as well. AFAIK you do not need to be a member to get
them in some RIRs.

	From the the allocation ISP stand point, locators would not be very
different than ASNs or IP addresses.

	I am not in favor or against to RIRs involved in LISP, I just want to
make sure we have all the information before making a decision.

Regards,
as

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 4 Mar 2013 06:40:59 -0500

>         Possibly, but, would it be very different than when RIRs started

It was free to members who already had IPv4.  That is an important distinction.

If the "LISP Experiment" only succeeds in issuing EID blocks to
organizations that already have their own IP blocks and are already
announcing to the DFZ, then IMO, it will not have been very
successful.

Why do you suppose I mention godaddy.com in my post?  If you want a
domain name, you can buy one.  That's probably not a good way to issue
IP addresses.  On the other hand, if you want a "green browser-bar SSL
certificate" they have additional identity and authority verification
hoops for you to jump through.  These steps are quite streamlined and
are performed efficiently by SSL certificate authorities.

My ideal world would allow someone to go get a "very small" block with
about the same hoops as a $10/year dot-com registration, hopefully at
a similar cost, and including a mapping service for xTRs to be able to
find your EID-to-RLOC mapping.  The MS relationship may be a tool for
reduction of abusive registrations that will invariably happen if the
bar to getting EID space is set very low.

A larger organization might jump through the extra steps and cost
required to get the green SSL certificate.  Then they can have more
address space, choose their own MS (maybe themself), and gain the
capability to sub-divide their allocation.

LISP is a pet project.  Personally, it makes me want to scream every
time someone talks to me about how great LISP is, or will be in the
future.  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 -- not just
in technical terms (like negative map cache entries, which are a
disaster) but also in business terms, like how do you get an EID block
so you can actually take advantage of this new technology.

RIRs are not effective organizations to be handing out EIDs to the new
kind of users that LISP is supposed to empower.  You need godaddy-like
companies to want to do this.  You might as well inch further away
from "pet project" by allowing one or more for-profit businesses to
gain experience allocating EIDs, and for the community to be able to
decide if it is a good or bad idea.

---

From: Arturo Servin <[email-masked]>
Date: Mon, 04 Mar 2013 15:54:34 -0200

> It was free to members who already had IPv4.  That is an important distinction.

	Nop, at least in the one that I know it was free as the air.

	Not sure about the others.

> decide if it is a good or bad idea.

	I though that LISPs users would be ISPs.

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

Regards,
as

---

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

I forgot to add.

http://www.apnic.net/services/apply-for-resources/kickstart-your-ipv6

	It may be: "If you already have an asn, just click here to start using
LISP" (or something like that):

http://your-rir.net/services/getyoureid

Regards,
as

---

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

> so you can actually take advantage of this new technology.

You make it scale up by starting to deploy something. That is where we are with LISP. If we do say it is great, it means we have received good results over the last 6 years. It is time to take it to the next level. Many people are interested in LISP, to deploy for their own use-cases, to fund companies to build specific products for specific use-cases, and to get infrastructure ready for the demand.

If there isn't a public mapping database system deployed, enterprises will do it themselves because it is easy enough to do. But we really don't want this to turn into many "private clouds" as we see with the various cloud based services being offered by industry. I think there will be private mapping database systems but I think there will also be public ones as well. The question is to try to avoid the complexities of a hybrid private/public. The same ones we see with cloud infrastructures right now.

Jeff, I see environments deploying overlays where all end-nodes are ONLY EIDs. So the negative map-cache entries don't even play there.

Dino

---

From: Sharon <[email-masked]>
Date: Mon, 4 Mar 2013 11:06:19 -0800

On Mar 4, 2013, at 10:30 AM, Dino Farinacci <[email-masked]> wrote:

> The question is to try to avoid the complexities of a hybrid private/public. The same ones we see with cloud infrastructures right now.

Don't think there is a way around dealing with this issue of " long-jumps"  between clouds vs within private clouds..  

...because one of most powerful aspects of lisp mapping is that it allows you to engage immediately and explicitly some very powerful and very much entrenched private identity systems such as  plmn or nfs .. 

.. you to may want to wire entities to functions internally one way, but expose-export public services another way .. 

.. it will be good to have a public anchor to set style and design according to .. like private mibs, intra-nets etc.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Mar 2013 11:14:29 -0800

Yes, all true.

Dino

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 4 Mar 2013 14:18:58 -0500

On Mon, Mar 4, 2013 at 1:30 PM, Dino Farinacci <[email-masked]> wrote:
> You make it scale up by starting to deploy something. That is where we are with LISP.

No, you're not.  You're thinking about maybe asking IANA to beg RIRs
to hand out experimental address blocks.  RIR memberships are likely
to say no if it even gets that far.  If they happen to say yes, it
will still create a very high barrier-to-entry for anyone to try to
participate in what you claim you're deploying.

You're also saying that no one should be able to profit from EID
registration so you reduce the potential pool of non-RIR-entities who
might be willing to provide this service, and become stakeholders in
LISP's success.

> If there isn't a public mapping database system deployed, enterprises will do it themselves because it is easy enough to do. But we really don't want this to turn into many "private clouds" as we s…

I'm sure it hasn't escaped your notice that the DNS system has many
registrars but only one delegation path for dot-com, etc.  Operation
of mapping servers could be decoupled from the registration service,
it could be a shared responsibility of several registration service
entities, whatever.

My point is that you haven't even thought about it.  All you seem to
have thought is, oh the RIRs should do it for us, and by the way,
let's make sure no one can profit from this.

If two or more RIRs can provide registration services, then so can two
or more ordinary businesses.  You know that, you've simply pretended
it isn't true for the purposes of arguing against it in your post.
That doesn't help anyone.

You don't even have to sub-divide the EID block in the discussed
manner to support multiple commercial registrars.

> Jeff, I see environments deploying overlays where all end-nodes are ONLY EIDs. So the negative map-cache entries don't even play there.

Yes, they'll just break xTRs.  See my previous postings on this topic.

As long as you pretend this is not a problem, you are obstructing any
possible improvements.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Mar 2013 11:25:14 -0800

> to hand out experimental address blocks.  RIR memberships are likely

Jeff, there are many paths to go forward. This ID is only a single path and if it doesn't pan out, it does not threaten LISP deployment.

We are just asking for a well-known prefix.

> might be willing to provide this service, and become stakeholders in

I am not saying that. I am saying I don't care how the business models are creative going forward. Let the market decide how this will go. And I certainly don't want to dictate or even suggest any models.

> it could be a shared responsibility of several registration service

Yes, it could.

> let's make sure no one can profit from this.

We wanted to try using a process that is already in place. There is consensus forming that RIRs may be the wrong place. I'm fine with that.

> That doesn't help anyone.

Umm, I'm confused. I made a suggestion. It could be way wrong. I wanted to generate discussion. We have accomplished that.

Agree.

> As long as you pretend this is not a problem, you are obstructing any

The solution works, has limited scalability, and there are many ways to avoid or get around it. They come at costs, and we have to make tradeoffs.

Dino

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 4 Mar 2013 14:50:23 -0500

> We are just asking for a well-known prefix.

I think you stand a better chance of actually receiving that prefix if
you have a realistic plan for delegating it to participants in your
experiment.  This is especially true if the system proposed looks more
like what a realistic, Internet-scale deployment of LISP might be in
the future.

The plan I've suggested is realistic and is what would be needed for
LISP to succeed in its future goals.  You should be cheering it on.
Instead you are making very foolish arguments against it, like "we
don't want fragmentation because ... cloud ..."  That fragmentation
actually benefits your project in numerous ways which I have outlined
in this thread.

If you want people to be able to raise money to start businesses based
on promises of LISP, you have a lot more chance of that being
successful, too, if someone can actually get an EID block without
learning how to deal with an RIR.

I suspect most people on this list haven't ever worked with the RIRs.
I do on a routine basis for dozens of clients.  They make life hugely
difficult sometimes, and other times they just go "okay here are your
numbers!" for no outwardly-evident reason.  Businesses shouldn't have
to pay people like me to help them navigate the process, but
unfortunately, they do.  You need to address that if LISP is going to
deliver on its promises.

There is NEVER going to be a better time to work toward that than
right now.  Right now, you are trying to get the EID block.  Right
now, you can decide that maybe it's valuable to try to get private,
competing businesses to efficiently and cost-effectively register IPs
in such a way that ordinary people can afford and accomplish it.

If you lose that opportunity you may not find it again later, and some
of LISP's promise may never be fulfilled.

Again, you should be my idea's cheerleader.  I will think of a good
mascot for when you realize I'm right and decide to go shopping for a
giant animal costume.

---

From: David Conrad <[email-masked]>
Date: Mon, 4 Mar 2013 16:22:04 -0800

Arturo,

> A new policy would be needed.

Which would require someone to go to each of the RIRs and initiate a policy proposal that says the RIRs undertake allocation/registration of EIDs. During the discussion of the policy, I suspect RIR staff would be asked "how much will this cost", which will result in staff going back and coming up with numbers that are fed into the policy deliberations which are then voted on (one way or another) at an RIR meeting. My impression is that this isn't a particularly quick exercise.  Would you be able to provide an estimate on how long you think it'll take for each of the RIRs?

Also, if some RIRs approve of getting into the EID Leasing business and some don't, does that mean the enterprises that live in the regions served by RIRs that don't want to hand out EIDs can't participate in the LISP experiments?

> Possibly, but, would it be very different than when RIRs started allocating IPv6?

Good question. My impression is that IPv6 allocations started to occur before policy definition processes became relatively heavyweight, but I might be misremembering.

>> Has that open policy development process been proposed in any of the RIRs yet?

To be honest, I'm still not convinced that it makes sense to partition EID space on geo-political boundaries. Do you think there is are any reasons to do so?

> could be different, but again, we need to ask.

My recollection was that RIRs had different policies, e.g., some required (at least) RIR membership and all required entering into some sort of legal Registration Service Agreement.  However, again I might be misremembering.

Regards,
-drc

---

From: Arturo Servin <[email-masked]>
Date: Tue, 05 Mar 2013 12:35:39 -0200

David,

	One of the good things of RIRs (IMHO) is the policy process and their
self-regulation, however that is also their Achilles heel when you need
something really quick and easy.

	It is true that you would need an individual or a group of them to make
a policy to mandate the RIRs to and it would take at least a few months
(to several months if the community do not find the policy appealing).

	May be RIRs are not the perfect fit for EIDs, but what other mechanisms
to support registration and services?

	A business org providing them as Jeff suggest? (I do not agree with him
and do not buy his arguments BTW)

	IANA?

	My suggestion to the draft authors would be to identify as Joel
suggested the requirements of the assignment of EIDs. Then contact RIRs
communities to see how good or bad is the idea to task RIRs with the
allocation of this new resources. Depending on that we could move forward.

Regards,
as

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 5 Mar 2013 09:42:25 -0500

> and do not buy his arguments BTW)

Perhaps you would prefer a document that creates more than one option?
 These need not be mutually-exclusive as long as the framework for a
multiple-registrar system is in place.

---

From: Arturo Servin <[email-masked]>
Date: Tue, 05 Mar 2013 13:02:11 -0200

Too complex IMHO.

.as

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 5 Mar 2013 10:52:26 -0500

>         Too complex IMHO.

The document?  You just ask the RIR(s) to become EID registrars.  They
don't have to be "special" and in fact, probably shouldn't be.

---

From: Arturo Servin <[email-masked]>
Date: Tue, 05 Mar 2013 15:42:33 -0200

On 05/03/2013 13:52, Jeff Wheeler wrote:
> The document?  

	Having two mechanisms to allocate EID. Private and RIRs.

You just ask the RIR(s) to become EID registrars.  They
> don't have to be "special" and in fact, probably shouldn't be.

-as

---

From: David Conrad <[email-masked]>
Date: Tue, 5 Mar 2013 10:38:24 -0800

Arturo,

> something really quick and easy.

I remain unclear as to the need for heavyweight policy processes and/or self-regulation in the allocation of flat namespace identifiers.  Neither were/are necessary for the allocation of PENs and the vast majority of the other resources the IETF has specified. Can you explain why you believe you need the RIR policy processes and complex self-regulator regimes for the allocation of EIDs? 

As I asked before:

>> if some RIRs approve of getting into the EID Leasing business and some don't, does that mean the enterprises that live in the regions served by RIRs that don't want to hand out EIDs can't participate in the LISP experiments?

I personally don't think it makes any sense to regionalize EIDs. You would appear to feel differently. Can you explain why?

> to support registration and services?

As Jeff points out, the services that need to be provided for the allocation, registration, and related services for EIDs are not that hard or expensive.  Where things get tricky is (a) scaling up to meet exponential growth and (b) dealing with inter-governmental politics.  At this point in LISP's evolution, I do not believe either are an immediate concern. 

> allocation of this new resources. Depending on that we could move forward.

I agree 100% with the first part.  I'm struggling to understand the need for the second part, but that can be deferred until the requirements are identified.

Thanks,
-drc

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 5 Mar 2013 14:45:55 -0500

> I personally don't think it makes any sense to regionalize EIDs. You would appear to feel differently. Can you explain why?

Regionalizing the EID numbers themselves is probably not beneficial.

Regionalizing the registration services has benefit.  That's why we
have RIRs.  It's also why RIPE has LIRs!

For example, if you are a small business in Eastern Europe, it may be
quite difficult and time-consuming for you to pay an international
invoice.  Many businesses would rather deal with an in-country LIR
than RIPE because the LIR allows them to acquire the resources they
need from a vendor who contracts under their local legal system, bills
in their currency, and speaks their language (literally.)

You may not want everyone to depend on, for example, and
English-speaking registry with 9-5 ET office hours that only bills in
USD.

---

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

If we have one set of criteria for how organizations can become EID 
assigners, then w have one simple and consistent set of rules.  The fact 
that some of the organizations who might choose to participate may wear 
other hats (RIR, DNS Registrar, ...) does not create in and of itself 
any additional complexity for us or in or document.

yours,
Joel

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 5 Mar 2013 17:41:54 -0500

On Tue, Mar 5, 2013 at 3:51 PM, Joel M. Halpern <[email-masked]> wrote:
> other hats (RIR, DNS Registrar, ...) does not create in and of itself any
> additional complexity for us or in or document.

The reason I suggest two types of orgs (RIR, DNS registrar) is because
ICANN has already effectively blessed them; or browser-makers have
done the same regarding the green SSL certificates.

I'm not suggesting to ask Mozilla Foundation who should be allowed to
issue EID blocks.  I'm saying there may be a way to avoid drafting
complex qualification criteria, asking someone to to evaluate
applications, lawyering, blablablah by relying on pre-existing
"blessings" given to DNS registrars.  Obviously the RIRs are
considered trustworthy stewards of IP numbers, too.

On Tue, Mar 5, 2013 at 3:40 PM, Joel M. Halpern <[email-masked]> wrote:
> Having said that, I take David's pont that we need something simple we can
> put in place now.

The simplest solution is for some company or institution to simply
volunteer to do it, or collaborate with one-another to do it.