Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

[Dino Farinacci <[e-mail]>]

> Dino, to come back on topic. I understand the drafts purpose is to request a block of IPv6 address be delegated for this specific purpose, from IANA. The request is to the IAB. So, its a request for architectural aspects of addressing, facing an experiment.

Sure.

> a /12 is a very large amount of space. This demands rigour in the process to apply, even a reservation requires a sense of why, and justification. "we think its about right" isn't appropriate and the document needs more work to specify why a 16, and why a /12, and what the implications are of eg a smaller allocation under a /16 reservation, or some other size (a /32 even, for which there are both precedents, in experimental allocations, and an existing process inside the RIR address management framework).

Okay.

> Secondly, you appear to assume these allocations to EID can simply use current RIR practices. The problem is that you need to understand what needs-based and justification means in process terms: Hostmasters in the RIR system try very hard not to be placed in a position of making arbitrary subjective decisions: they have processes which are designed to ask for objective justifications to specify why an allocation should take place, and at what scale. Those objective criteria face addresses as addresses. not EID.

No, I am not making any assumptions either way. How allocation gets done is subject to more work.

> For an example: IPv6 address allocation process currently is implemented using sparse allocation (binary chop with some modifications) in the APNIC region. This maximises space around allocations to equalise the distribution of free blocks such that the commons, the unallocated space, remains as usefully large as possible and when the next binary stride is entered, there is some understanding its going to be applied in common to all occupants of that region of space (in terms of the size of hole around them, which is not a reservation per se, but provides for risk-management of future growth to the largest extent).

There is no special semantics of EIDs that require you to change this. EIDs are just addresses that do not get injected into the underlying routing system. Other than that, they are just like any other address an RIR allocates.

> We're really quite proud of sparse: its extended the life of the /12 we occupy quite markedly. What impact will EID have on this? Is sparse an appropriate allocation engine to use for EID? What if eg you have expectations of almost-geographic aspects of address management in EID. Doesn't that require documentation as a process? And, you may be specifying a cost on the RIR system, to engineer support for the new allocation logic. If it doesn't logically fit in sparse allocation, we need to know. And we need to know why.

What Joel said.

> EID are not going to be used like 'normal' addresses. So, the normal justifications don't look entirely

Define how a 'normal address" is used.

> appropriate to me from 10,000ft. The document needs to say "maybe we need to understand the allocation processes that the RIR should objectively apply" or maybe you need to step outside of draft space and engage inside the RIR policy process and seek a global policy which can document the process.

The working decided that this draft is solely for request purposes. We could use help from RIRs to write a document on how to allocate EIDs. But I am pretty sure it would look like documents that already exist.

I don't understand why you think they look different or need to be treated differently. So you have to do the explaining.  ;-)

> To ask for an IANA allocation without having undertaken this process looks wrong to me. So, I stand by my concern the document isn't ready for IETF last call: it hasn't addressed substantive issues around the process and expectations of address/registry function, to manage the /16, and it hasn't documented the basis of asking for a /16 in the first place, or a /12 reservation.

Here is a real world example we have been using on the LISP beta network. It is so simple that it really needs no more explanation than what I am going to explain below:

(1) We have 2610:00d0::/32 allocated for EIDs.
(2) Each site on the LISP beta network gets a /48 out of that.
(3) Each site xTRs register their /48 with the mapping system using RLOCs that are PA addresses they use to attach to the Internet.

That is it. So I am not getting why there are so many issues. Can't we keep this simple and experiment please?

Dino

> 
> cheers
> 
> -George