Hi Geoff, thanks for your review.
Comments are inline. On 21 Feb. 2014, at 10:27 , Geoff Huston <[email protected]> wrote: > > On 15 Feb 2014, at 3:34 am, [email protected] 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 > > > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
