> Dino, > > On Mar 2, 2013, at 1:13 PM, Dino Farinacci <[email protected]> wrote: >> Who do you think should allocate them? > > Without knowing all the management requirements and services necessary to > meet those requirements, it is challenging to say.
Well my steps below cod be taken as requirements. >> 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? > > One issue I have with the draft is that it appears to start out with "use the > RIRs" without considering the implications of using the RIRs or even defining > what the RIRs are supposed to do or the limitations on how they will do it. I believe the intent was to just have an allocation entity so EID-prefixes could be allocated uniquely. And the RIRs were chosen because they exist and already do that function. If we all agree they are the wrong entires then we can come up with a newer model. > I'd argue the first step would be to define the "minimal policy" to be, e.g.: > > - allocations MUST be globally unique Yes - a strong requirement. > - requirements for allocation MUST be the same globally, no > regional/national/local variation I won't disagree. But if we say the EID-prefixes are globally unique then how could they be different. There is no provider variable here to complicate matters. > - allocations MUST be <size or way to determine size> Agree. > - allocation service MUST be provided at no more than cost > - registration data MUST be maintained and be made publicly available via > <something, e.g., whois> Agree in that. But you shouldn't dictate a cost though. Some may want to bundle allocation with something else so their costs could be more but they cover with different revenue sources. > - registration maintenance MUST be provided at no more than cost If you are talking about Mapping Database registration? If so, they should beefy out since that is an independent service. > - reverse dns SHOULD be provided > - the service MUST be available <service level commitments> I view EID assignment as a one-time transaction and not a continual service. DNS, mapping database services happen else where. We want the end-sites to have independent (and asynchronous) relationships with all these entires so they can change any without having a dependency graph to change the contingents. Here are the entires: (1) Data-plane service provider (an ISP). (2) Control-plane Mapping Service Provider (MSP). (3) A one-time transaction EID-prefix allocator. (4) A DNS service provider. The only one above we don't have in wide-scale deployment today is (2). > - etc. > > Once you define the minimal policy, I personally believe the right answer >From our email exchanges thus far, do you think we have? > would be to leave it to IANA to figure out how the service which meets that > policy should be provided but that's an implementation decision. I don't > think the bodies by which service is provided should be defined in the > document. That is a very reasonable comment IMO. >>> 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. > > Not an issue (well, at least for me). > >> (2) Divides up equally to RIRs. > > Why? What benefit does this provide? Is it (e.g.) a policy goal for EIDs to > have different allocation requirements based on geo-political location of > requester? No - no geo-political requirement. So we could have the IANA do all allocations. > Having _an_ RIR provide allocation and/or registration services might make > sense since it already has at least some of the infrastructure to provide > those services but this makes the assumption that the RIR's membership thinks > this is something the membership fees should pay for. > >> (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. > > (skipping over a discussion on the need to have contiguous blocks of EIDs for > the same corporation) > > The vast majority of corporations (excluding ISPs) don't know (and probably > don't want to know) the RIRs exist. I also doubt they want to get into the > whole RIR membership/political world. By putting EIDs in the RIRs, you're > forcing those corporations to (a) figure out which RIR they "belong" to, (b) > pay RIR fees, (c) potentially (almost certainly in the ARIN region: look what > happened with RPKI) enter into Registration Service or other legal > agreements, etc. Okay - fine David. We are not forcing this and the draft could be changed. You are making a point, I think, by putting this EID allocation requirement into the existing RIR structure is more complicated then doing it a different way, I think people on this list are all ears. > I strongly suspect that particularly for an experimental service, you want a > single point of entry into something as simple, low cost, and lightweight as 100% agree. So you are saying dont use the RIRs. Please let me know if I misinterpreted any of your points. I am trying to make some conclusions. > possible, e.g., something like http://www.sixxs.net/tools/grh/ula/list/ Yes - I believe that is all that is needed for EID-prefix allocation. > or IANA's PEN allocation/registration service. However, as mentioned, without > knowing the requirements, it's hard to say for certain. > >> Is that too simplistic? And if so, why can't it be. > > The RIRs aren't simple. This email thread has already proven that in my mind. :-) > > Regards, > -drc Thanks, Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
