Okay, we need to reset this thread. A little history: (1) I originally suggested to request IANA for a well known /12 prefix that was known to be an EID prefix where you could be guaranteed to have xTRs deployed at the site.
(2) I requested this so when a packet hits an xTR at a LISP site with a destination address not in the /12, AND a configuration knob was set, the packet could be routed natively to the non-LISP destination site. That is all I wanted out of the /12. It was a way to make LISP to non-LISP communication avoid a mapping database lookup that would yield an answer of "destination is not LISP", which the well-known prefix would tell us right away (yes, by hard coding it). The thread has wandered into: (1) How will registries allocate and how will sites get EID-prefixes. (2) How can LISP succeed without such coordination EID allocation. (3) If this is experimental versus production. Where in fact, any address today can be used as an EID-prefix by simply allowing an xTR to look it up (the configuration knob above is not set) to determine if there are xTRs at the site. This is why I keep saying there is no requirement for RIRs to allocate EID-prefixes. Dino On Mar 12, 2013, at 4:47 PM, John Curran <[email protected]> wrote: > On Mar 12, 2013, at 7:36 PM, David Conrad <[email protected]> wrote: > >> On Mar 12, 2013, at 4:21 PM, John Curran <[email protected]> wrote: >>> The choice of going with a single registry with neither competition or nor >>> elected >>> oversight may also work, but places enormous faith in the enduring best >>> intentions >>> of the enlightened and benevolent overseers, particularly once there is >>> significant >>> usage and a complete lack of viable alternatives. >> >> I dunno -- IANA seems to have done pretty well with the 1000+ protocol >> parameter registries they manage with lightweight oversight by the IETF/IESG. > > Indeed. While I don't believe any of the parameter registries are as > widespread and pervasive as what is intended with EIDs, there is no > reason to believe such scale isn't achievable. I was only noting that > the reasons expressed on the list for having a registry/registrar split > included more than just "scalability". > > FYI, > /John > > Disclaimers: My views alone. This email sold by conceptual weight not volume. > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
