On Mar 13, 2013, at 8:47 AM, Terry Manderson <[email protected]> wrote:
> To restate - "who" is not open for discussion. Please keep to the > technical specification of 'how'. Acknowledged, and this approach makes perfect sense. The question on the table is "how" to manage the EID prefix proposed in [I-D.ietf-lisp-eid-block]. I posed two questions yesterday that would help clarify the scope of this task, and I believe (based on the rambling discussion on the list) that some progress has been made on both of them, but obviously would like to hear from others on their views: > 1. Is the current LISP Beta network mechanisms for EID block assignment > insufficient for the task at hand (or expected to be insufficient in the > near > future)? Knowing whether we've got a handful of months versus a few > years > to work on the EID management requirements may be important in deciding > what can be reasonably included in the scope (and aspirations) of the > requirements. I believe that Dino clarified that it is not, per se, aspects of the current EID management that creates a need for the EID prefix, but a potentially significant architectural benefit of being able to create a knob which could avoid numerous mapping lookups for non-LISP Internet destinations. No one has otherwise indicated that we're facing some form of collapse in the current EID management, which would imply that there is enough time for a thorough considerations of the requirements. (if this is incorrect, someone should speak up on this point.) > 2. Is it actually acceptable to setup a _truly_ temporary EID management > framework (i.e. with the potential that the assignments would actually be > revoked some number of years from now), or is it true that the EID > management framework being specified effectively "must succeed" in > some form or another, and hence we are really detailing the long-term > architecture and not just an experiment? If this truly is an experiment, > and we will have the freedom to cast it aside and replace it with > something > better 10 years from now, that would put the requirements in an entirely > new perspective. This question remains open and is fairly important to resolve before proceeding. The degree of rigor put into "how" we manage the proposed EID block is likely going to vary widely depending on whether the "experiment" actually can be shutdown after years of deployment. If folks have decided not to use LISP, then its fairly simply, but should LISP be as successful as hoped 10 years from now, then this "experiment" will be the production approach to managing the EID block. Add in consideration of 10 years worth of sites setting the "outside /12 is traditional Internet" mapping flag, and it's clear that deploying LISP using some other space (e.g. via traditional IPv6 prefixes) will not even be an option. It is also quite uncertain how or whether any operational services provided by the "experimental" EID registry could safely transitioned to a new management model without endangering existing EID users in the process. In light of that outcome, if there is any reason not to take the time to fully plan out the management approach as the initial _production_ solution (not experimental), then it has not been expressed on the mailing list. The last time we set to do something so fundamental and left major pieces as future work was with IPv6 and its transition plan [RFC 1752] (and I very much doubt we want to repeat that particular success.) Since we are actually establishing the management approach for the identifier space of the future Internet, the task should be scoped accordingly and the "how" should be fully considered and spec'd as the long-term solution. FYI, /John Disclaimers: My views alone. Steep precipice ahead - look down with care. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
