Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-mgmnt-01.txt

[Luigi Iannone <[e-mail]>]

Hi Geoff,

thanks for your review. 

Comments are inline.


On 21 Feb. 2014, at 10:27 , Geoff Huston <[e-mail]> wrote:

> 
> On 15 Feb 2014, at 3:34 am, [e-mail] wrote:
> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF.
>> 
>>       Title           : LISP EID Block Management Guidelines
>>       Authors         : Luigi Iannone
>>                         Roger Jorgensen
>>                         David Conrad
>> 	Filename        : draft-ietf-lisp-eid-block-mgmnt-01.txt
>> 	Pages           : 13
>> 	Date            : 2014-02-14
> 
> 
> 
> section4, bullet 5 states:
>       All allocations (renewed or not,
>       including delegations and sub-allocations) MUST be returned by 31
>       December 2020, in accordance to the 3+3 years plan outlined in
>       [I-D.ietf-lisp-eid-block].
> 
> 
> but the text at the end of the section reads:
> 
>   If/When the EID block experiment changes status (e.g., to not being
>   "experimental"), and following the policies outlined in [RFC5226],
>   the EID block will change status as well and will be converted to a
>   permanent allocation. 
> 
> 
> Bullet 5 states "MUST be returned" and the later text states "will be converted to a permanent allocation"
> 
> This seems to be a contradiction. What's the intended plan? 
> 

Indeed there is a contradiction. The end of the section is actually a relic of previous versions of the document. 

I would just delete the last paragraph. The plan discussed during the last WG meeting was to put a “deadline” at 2020. 

By that time there will be sufficient deployment experience to decide whether or not have a permanent allocation (or “renew” the experiment).



> If the permanent plan is that LISP runs from corralled space, then I am seriously concerned that this is an admission of failure of LISP from the outset.

LISP does not need such a corralled space. 

There point of the experiment is to understand if by having a dedicated LISP EID space any technical benefit can be achieved. 

Since the community seems to be split on this topic the experiment can give the answer.
 

> I though the object of the exercise was to offer LISP as a routing protocol with superior scaling properties to what we have now. But if this entails renumbering the Internet to achieve it, then just renumbering the Internet so that the address structure aligns with the topology of the network would allow the existing protocols to also scale - so where is the "win" in LISP?
> 
> At the very least it would be good for the draft to clarify the directives of must be returned and the conversion to a permanent allocation.

No permanent allocations ;-)

The IETF will decide between 2017 and 2020 what to do afterwards and how to do it. 

> 
> But I would also like to understand the longer term issues at play here - is the longer term plan for LISP to route the Internet's unicast address space as deployed, or are we truly contemplating a lengthy transition into an essentially renumbered space?

There is no renumbering needed with LISP, it is just about adopting the technology.


Luigi

> 
> Geoff
> 
> 
> 
> 
>