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 On 22 Feb 2014, at 3:52 am, Dino Farinacci <[email protected]> wrote: > 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 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? >> >> 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 >> >> >> >> >> >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
