Hi,
A possible course of action for the LISP Working Group and the IESG to
consider would be for the existing /32 address be documented as an IANA
Special Purpose Address allocation for use in supporting the current
LISP experiment, and for the LISP advocates to make their case for
particular requirements in the handling of global unicast address
allocations in IPv6 to the regional addressing communities. This would
allow the existing address policy development process to generate
outcomes that appropriately address the desires and concerns of the
broader community of stakeholders in supporting the potential
requirements of a broad base of deployment of LISP in the Internet's
routing environment.
So, if I understand you correctly you say that this should be a (global?)
policy proposal in the different RIR regions. Is that correct?
If yes, then that could mean that every region allocates/assigns LISP prefixes
from a separate block. Together with the current experimental /32 that would
mean 6 prefixes for LISP in total. That's not as ideal as a single prefix, but
still very acceptable for the BGP table.
If this wg agrees that this is the way forward then there are a few things that
should be done as far as I can see:
- Define when the current experiment with the /32 is successful
- Document a vision of how LISP should be deployed using a few prefixes that
cover all the LISP space
- Advise on how LISP prefixes could/should be assigned
- Probably also looking at different phases, for example:
- Early adopters: separate PITRs+BGP routes for each /48?
- Middle: central PITRs covering the whole LISP space (public? in tier-1
nets?)
- Long term: LISP PITRs in all major networks
- Describe a strategy to go from each phase to the next
- How to deal with the prefixes if LISP isn't as widely accepted as we hope
- Writing a (global?) policy proposal for assignment of LISP prefixes
- Submitting that proposal to all RIR regions and try to get consensus there
I think that if we do the above we can show the operators a possible future
where the BGP table isn't cluttered with PI prefixes. Worst case we end up with
a prefix in BGP for every LISP end-site, but that's no worst than with current
PI assignments. Best case we end up with a much smaller routing table (compared
to normal PI) where all those end-sites are covered by a few prefixes. IMHO the
most important thing is to plan on how to get there :-)
And yes: of course I volunteer to help writing this stuff :-)
Sander