> Dino, > > I personally don't believe you want to open the EID space up to the policy > regime associated with PI space.
Hey, if it can be simpler than the PI policy regime, then by all means. I just didn't want people to think that LISP EIDs needed *more* process/policy. > There does not appear to be any technical justification to do so and the > political baggage you'd be inserting EIDs into does not appear worth the > cost. Well I will yield to you on such things. > Do you really want 5 different sets of policies constraining how EIDs are > allocated? Does it make any sense for a multi-national corporation to have to > go to multiple organizations to get EIDs because RIR policies require use of > resources exclusively in region? Is it really necessary to go to up to 5 > different Whois servers to figure out who an EID is registered to? (I could > go on but I'll stop now :)). This is exactly the reason we protocol designer need help from you allocator types. If the process gets too complicated, people will get their addresses the way they do today and can and will use them by EIDs. How a corporation advertises its EID-prefixes (via BGP route advertisement or Mapping Database registration) will be their decision. > Simply: I believe you want a single global policy under which EIDs are > allocated. That's not how the RIRs work. Yes, that would be best IMO, and simple. > If (for whatever reason) folks do not feel IANA is the right place to > allocate EIDs, I might suggest pushing this onto the IAOC (or whichever > acronym is appropriate -- maybe in an IANA considerations section?) to do an > RFP and allow the RIRs (and whoever else might want) to bid on a contract for > providing global EID allocation and registration services. Who do you think should allocate them? If we want minimal policy and just need a well known prefix, why can't IANA just allocate a /16 for the 10 years that Luigi indicated in the draft? > However, I believe this is putting the cart in front of the horse -- the > first step should be figuring out what the services are that need to be > provided. Would you agree to this: (1) IANA allocates a /16. (2) Divides up equally to RIRs. (3) When RIRs get requests from corporations, they give them /64s (I won't argue if it is /48, /56, or /64), leaving some holes so subsequent requests can be best fit to the same corporation. Is that too simplistic? And if so, why can't it be. Dino > > Regards, > -drc > > On Mar 2, 2013, at 12:09 PM, Dino Farinacci <[email protected]> wrote: >> How about this as an alternative: >> >> (1) RIRs allocate EID space as they do PI space today. >> (2) RIRs should not couple routing with allocation so they should not care >> about EID space advertisement in the core or in the mapping database (unless >> they are providing a mapping database service, which I suggest). >> (3) Data-plane providers decide where they provision PITRs and decide what >> coarseness of EID space they advertise. >> >> Dino >> >> On Mar 1, 2013, at 10:31 PM, Arturo Servin <[email protected]> wrote: >> >>> >>> Because the draft is about IPv6 unicast space. Currently that is >>> managed to the RIRs and IANA which seems to work well, not perfect. >>> >>> So far, no body has given an alternative to manage that space besides a >>> collaboration among the RIRs as in this one. >>> >>> If you have an alernative I would love to hear it, but not just say >>> that you do not want to go into the RIR system without a feasible >>> alternative. >>> >>> Best regards, >>> as >>> >>> P.D. Same as previus, rir hat off >>> >>> On 01/03/2013 17:03, Joel M. Halpern wrote: >>>> Could you please explain why you beieve it is important to consider the >>>> RIRs? It is quite possible I am missing something. >>>> >>>> As a participant, I believe I have said clearly that I prefer that we >>>> spell out what our allocation / delegation / application behavioral >>>> requiremens are, without specifying who would meet them. >>>> >>>> My expectation is that this would result in something where there RIRs >>>> could participate, and where non-RIRs could also participate withot >>>> going through the RIRs. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 3/1/2013 8:55 AM, Arturo Servin wrote: >>>>> <rir hat off> >>>>> >>>>> I think that going forward withou considering the RIR system would be a >>>>> big mistake (by either ignoring them, or doing something without asking) >>>>> >>>>> I haven't read the draft carefully (I will) but I think that if the >>>>> authors' intention is to promote a dialogue, it is in good direction. >>>>> >>>>> </rir hat off> >>>>> >>>>> Regards, >>>>> as >>>>> >>>>> On 28/02/2013 03:52, Roger Jørgensen wrote: >>>>>> On Wed, Feb 27, 2013 at 8:44 PM, Joel M. Halpern >>>>>> <[email protected]> wrote: >>>>>>> That similar. My point is specifically to stay out fo "who" except >>>>>>> for the >>>>>>> root. >>>>>> >>>>>> excellent, think we can agree on that really, and that's one >>>>>> direction to think. >>>>>> >>>>>> I would really like to hear if any other have other possible direction >>>>>> we can consider, either with or without existing RIR system. >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
