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

Joel,

        I think that George raised a very valid concern and he explained very
well the RIR machinery to perform address allocation.

        Saying that "it is just PI" simple does not help.

        As an example of our concerns (or at least mine), the policy to
allocate PI in lacnic is:

"
4.5.4.1. Direct assignment of portable IPv6 addresses to End Sites
having portable IPv4 addresses previously assigned by LACNIC
LACNIC will assign portable IPv6 address blocks directly to end sites if
they hold portable IPv4 addresses previously assigned by LACNIC.
In case of announcing the assignment on the Internet inter-domain
routing system, the receiving organization shall announce the block
maintaining de-aggregation to a minimum in accordance with the
announcing organization's needs.
Assignments will be made in blocks smaller than or equal to a /32 but
always greater than or equal to a /48.
Where possible, subsequent allocations will be made from an adjacent
address block, but only if duly documented and justified.

4.5.4.2. Direct assignment of portable IPv6 addresses to End sites not
having portable IPv4 addresses previously assigned by LACNIC
LACNIC will assign portable IPv6 address blocks directly to end sites
that satisfy the following requirements:
Not be an LIR or ISP.
In case of announcing the assignment on the Internet inter-domain
routing system, the receiving organization shall announce the block
maintaining de-aggregation to a minimum in accordance with the
announcing organization's needs.
Provide detailed information showing how the requested block will be
used within the following three, six and twelve months.
Submit addressing plans for at least a year, and host numbers on each
subnet.
Submit a detailed description of the network topology.
Prepare a detailed description of the network routing plans, including
the routing protocols to be used as well as any existing limitations.
Assignments will be made in blocks smaller than or equal to a /32 but
always greater than or equal to a /48.
Where possible, subsequent allocations will be made from an adjacent
address block, but only if duly documented and justified.
"

        So, are you expecting these to be the rules over the /16 that you are
requesting?

        As I said to Dino, you are free to leave the rules for later
definition, but that IMHO would demerit the request making the space
basically useless.

Regards,
as

On 15/11/2012 20:39, Joel M. Halpern wrote:
> 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
> > lisp(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/lisp
> _______________________________________________
> lisp mailing list
> lisp(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/lisp