Hi Dino,
Nothing is coming. Nothing really needs to change.
But if there is anything written up to define allocation procedures, the RIRs
can review such a document.
The main motivation for this prefix is to optimize ITRs so they know that a
destination is in a LISP site. This COULD eliminate a mapping database lookup
for a destination not in this range. Meaning, if a packet is destined to a
non-EID, you may know this by inspecting the address rather than asking the
mapping system.
I don't agree. For example: I'm using regular space for LISP EIDs now, so you
can't assume that if it's not in this block that it's not in the mapping
system...
This draft is purely a draft to REQUEST space. There will need to be a
deployment guide on how to allocate EIDs, in general.
And if the RIR system is used every RIR will develop its own policy for
allocating EIDs independently (hopefully based on the recommendations in
such a deployment guide). It will have to be very clear whose responsibility
it is to allocate from this space, and when assigning responsibility it
might be a good idea to make sure they accept that responsibility too.
Right.
Note that I am not opposing the idea. I'm just trying to make sure this
address space doesn't disappear into a black hole because nobody takes the
responsibility to manage it.
One thing we have to be very careful with here is that EIDs are not directly
allocated/assigned to end sites from this block. That will cause everyone to
independently find (different) PITRs for their space,
Why not?
Because the RIR communities will probably just refuse to allocate from this
space if it means that all those routes end up in the BGP table... They are
already plenty of people that don't like regular PI policies...
which will make a mess of the global IPv6 routing table...
And why do you think you need to assign PITRs per sub-block?
I hope that is not necessary, but if addresses are assigned to end-sites
directly in a PI-like way then who is going to provide PITR services for the
users? Someone has to pay the bandwidth cost for operating a PITR... And the
users of that space want reliability, so they are not going to rely on the
goodwill of some unknown 3rd parties. There is too much bad experience with
2002::/16 for that.
If you see another way that I am missing please let me know! I want this to
work, I just don't see how...
- Sander