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

[Sander Steffann <[e-mail]>]

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