Whatever else is going on, LISP EIDs do not have geographic
significance. They do not have IP Routing topological significance.
The are not aggregateable.
They are intended to beused by a site as a single prefix. Hence, the
desired behavior (within the /16) is exactly the same as that needed to
respond to a PI request.
Yours,
Joel
On 11/15/2012 5:24 PM, George Michaelson wrote:
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.
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).
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.
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).
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.
EID are not going to be used like 'normal' addresses. So, the normal justifications don't
look entirely 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.
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.
cheers
-George
_______________________________________________
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp