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
