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

From: [email-masked]
Date: Fri, 14 Feb 2014 08:34:39 -0800

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

Abstract:
   This document proposes an allocation framework for the management of
   the LISP EID address prefix (requested in [I-D.ietf-lisp-eid-block]).
   The framework described relies on hierarchical distribution of the
   address space with sub-prefixes allocated on a temporary basis to
   requesting organizations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-eid-block-mgmnt-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Geoff Huston <[email-masked]>
Date: Fri, 21 Feb 2014 20:29:25 +1100

> 	Filename        : draft-ietf-lisp-eid-block-mgmnt-01.txt

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? 

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. 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.

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?

Geoff

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 21 Feb 2014 11:01:59 +0100

Hi Geoff,

thanks for your review. 

Comments are inline.

> 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?
> 

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…

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

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Feb 2014 08:52:24 -0800

LISP does not require remembering. And many (100s) sites are using addresses they already have been using pre-LISP from non- corralled allocations. 

Dino

> On Feb 21, 2014, at 1:29 AM, Geoff Huston <[email-masked]> wrote:
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Geoff Huston <[email-masked]>
Date: Sat, 22 Feb 2014 08:23:46 +1100

Thanks for this Dino - Luigi has already cleared up my comments and questions on the draft by noting that the comments about conversion to a permanent allocation were intended to have been omitted from the draft.

Geoff