At 13:02 09-01-2013, Roger Jørgensen wrote:
I have tried to write down one way to get this done in a way that
handle most aspect. First a summary since this is a very long email.
The size of the address blocks are a suggestion from my side.
I'll make the counter-arguments.
* we reserve a /12
* LISP EID block are marked as EXPERIMENTAL with a time limit, let's
say 7year, until 10.October 2020 (not random picked, but 10.10.2020
seems nice).
* set aside one /16 for each RIR
* out of this /16 _only_ upto /26 split into /32 (64 for each RIR
region) can be can be handed out and announced into the global routing
table. If someone need something more than /32 they should really come
up with a very good reasons now or just ask for regular RIR space
* before 1.January 2019 IETF will have to decide if the EXPERIMENTAL
was a success or a failure.
** If failure the entire address block are taken back before 31.Nov
2020, filtering etc like 6bone.
** If a success, we remove the 64 /32 (/26) limit and each RIR can
hand out LISP EID space from the above /12 in their region, much like
regular space.
* in the EXPERIMENTAL phase (until 31.November 2020) one RIR/entity
keep track of the above /32 and a LISP-EID-wg decide and make up the
procedures for how this should be used.
This would be a long-lived experiment. It rarely
works well in practice as the people who set it
up might not be there to clean up the mess. It's
not a huge problem to ask for some IP address
space to reserved. I am ignoring a few details
which might point to that being a problem.
The "if someone needs more space" makes it a IP
address allocation problem. Someone will have to
deal with that request. The IETF does not do
that. I pointed to "operational models" in an
unrelated draft so that people can have at least
a little information about the options and decide
which option they prefer. I prefer to avoid a
6to4 scenario as making anything historic is a
recipe for debate. I don't like legacy space
because I am creating a problem for someone else to sort out.
At 13:37 09-01-2013, Joel M. Halpern wrote:
And this gets to the reason why specifying the
allocation policy will take a lot longer.
Not really. It's only agreement that takes longer.
From what I understand of LISP, and speaking
only as an individual participant, it is not at
all obvious tome that the RIRs have an inherent
role in LISP EID allocation. LISP EIDs are not
regional in any meaningful sense.
The reality is that RIRs are currently managing
IPv6 address allocations. It does not bother me
if IETF participants decide to give some other
entity the responsibility to do the work as long
as there is a clear explanation.
It is a lot of work to do an analysis of the
various alternatives and figure out the better
alternative. The proposal made by Roger
Jørgensen is a step forward. Geoff Huston
explained some stuff. I think that his comments
may have been misunderstood. Brian Carpenter
pointed to some interesting operational questions
that have been raised or implied. I may be
missing them as I don't have a clear sense of how
the working group wants LISP to work.
At 04:04 09-01-2013, Luigi Iannone wrote:
Not really, truth is that it was suggested to
look at ORCHID, hence we tried to provide the
same elements (or equivalent) that the ORCHID document provided.
Although there may be some elements in common the
problem is different. The considerations were
different and the environment was different when ORCHID was approved as a RFC.
Regards,
-sm
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
