I'll remove myself from the cc since I'm on lisp@ :-)
I have tried to write down one way to get this done in a way that handle most aspect. First a summary since this is a very long email. The size of the address blocks are a suggestion from my side. * we reserve a /12 * LISP EID block are marked as EXPERIMENTAL with a time limit, let's say 7year, until 10.October 2020 (not random picked, but 10.10.2020 seems nice). * set aside one /16 for each RIR * out of this /16 _only_ upto /26 split into /32 (64 for each RIR region) can be can be handed out and announced into the global routing table. If someone need something more than /32 they should really come up with a very good reasons now or just ask for regular RIR space * before 1.January 2019 IETF will have to decide if the EXPERIMENTAL was a success or a failure. ** If failure the entire address block are taken back before 31.Nov 2020, filtering etc like 6bone. ** If a success, we remove the 64 /32 (/26) limit and each RIR can hand out LISP EID space from the above /12 in their region, much like regular space. * in the EXPERIMENTAL phase (until 31.November 2020) one RIR/entity keep track of the above /32 and a LISP-EID-wg decide and make up the procedures for how this should be used. now some more text why I've come up with this suggestion: On Tue, Jan 8, 2013 at 7:03 AM, Terry Manderson <[email protected]> wrote: <snip> > The Responsible AD and the LISP chairs have discussed the future of this > document. We believe that the future of this document could be best served > by splitting it in two (one that allocates/justifies the prefix, and one > that describes the LISP specific allocation mechanism) and also altering > text to address the concerns raised during the IETF LC. Keep it as one document for the moment... > However, before the WG starts to rework the document, I would first like to > canvass the LISP WG as to your opinions. > > 1) Should we, as a WG, continue to work on this item? Is it necessary/useful > for LISP? yes it is useful... > 2) If so, what direction should the WG take this document so that the LISP > experiment is best served? > > I'd also like to call on those folks (as Brian did) who offered review of > this document (CC'd here) during the IETF last call to participate on the > LISP mailing list as to its future. The key word here is EXPERIMENT as I see it _now_. I found this post a while back http://www.ietf.org/mail-archive/web/lisp/current/msg04000.html <start copy> From: Luigi Iannone <ggx at gigix.net> To: Roger Jørgensen <rogerj at gmail.com> Cc: ietf at ietf.org, lisp at ietf.org Date: Thu, 15 Nov 2012 14:22:50 +0100 <snip> > I have to ask, who can request an netblock from this address space and > from where? Who: whoever is willing to deploy LISP. Where: your RIR? > I might be blind but I couldn't find it mentioned anywhere. > The purpose of the document is not to create a new way to distribute prefixes with its own policies, rather to use the existing "process" but just creating a code point specific for LISP. <end of copy> The problem here isn't so much WHO, it's more WHERE to get it. If we involve the RIR we end up in a complicated process. Complication don't always go well with EXPERIMENTAL processes. The other important thing that hasn't been mention that much is HOW it should be routed in the global routing table. This partly involve WHO but more about this later. First WHERE. When I read section "3. Rationale and Intent" in the draft I understand that the purpose is to reserve a large block so you can easier handle LISP EID space different than "regular" IP space on the configuration level. The EID Block will be used only at configuration level, it is recommended not to hard-code in any way the IPv6 EID Block in the router hardware. " Combine this with the keyword "experimental" I would say this give us a situation very alike to 6bone for those that remember that. Easy addresses to get but you _knew_ you might had to change your prefix and configuration at some point in the future. It's an EXPERIMENT. First of all, let's change the "recommanded not to" into "MUST NOT be hard-coded" or similar. Vendors are free to provide examples but it must be possible to change it. Then we add another section into the draft that mention this is a _time limited_ experiment, let's say around 7 years or so Reason for this follow 1.) 1/2 to 3 years to get LISP support from more vendors 2.) 1/2 to 2 years to plan, design and implement a setup using LISP EID space 3.) 1-3 years to get more deployment of it so we can learn and see how it works out 4.) we'll first see the real result of this in 2-5years time... I know it's not possible for me to get a larger none-test LISP deployment in place before in 1-2years time. With the above mention update we now have a clearly defined experiment with a time frame. This make it easier to solve the WHERE. If we could get one RIR or some other entity to take on the job free of charge to keep track of this LISP space, they should * provide whois service and documentation on who has valid LISP EID space * provide a framework for asking for LISP EID space * handle registry service for this space according to some guidelines given by LISP-EID wg (1*) This entity should probably not decide who can get, and who can not get LISP EID space, that's upto LISP-EID wg (1*). I would suggest RIPE or someone else with enough manpower and active people involved in LISP work. The last problem with WHERE is the management body (1*), LISP-EID-wg. I would suggest this work sort of similiar to how 6bone worked. I say LISP-EID-wg and not LISP wg since the latter are more involved in the development of it. Many of the same people but different focus. Their lifetime are anyway given by above time frame. This bring us onto WHO and more important HOW - Someone will have to announce something in the global routing table. We can think back to how well 2002::/16 worked as other also has mention. I think the lesson learned from 2002::/16 was that we can not have one huge net block many ASN's are announcing. I suggest we split the reserved /12 into some smaller blocks, set aside a given size for each RIR region (one /26) and for each RIR region the above LISP-EID-wg can give out /32 space until it's empty. I would say the experiment are a success IF most regions run out of space within the first 5 year really. At that time we just decleare it a success, remove the EXPERIMENTAL including the artificial /26 limit and let each RIR handle LISP-EID space almost as regular space... :-) About WHO, anyone being a LIR can ask for a LISP-EID space directly. The reason are that the net-block has to be announced into the global routing table. Everyone else will have to ask one of the few having space for a connection... I realize this open up a monopolistic situation really... anyhow, if we run out of space in the EXPERIMENTAL pool isn't that a success when more than 64 ASN in one or more region are using LISP EID space ?:-) About HOW. ASN holders can request it through above mention system, LISP-EID-wg will have to decide what is the best for the overall EXPERIMENT, that mean quite alot of ISPs might get a no on their request. That should be well understood. This is not regular IPv6 address space. This space is also limited and it will be reachable in the global routing table. The overall impact on the rest of Internet are marginal. Another question, should we consider, or have an opinion regarding how it's exchanged between participants? Again, since this is a EXPERIMENT, I would suggest we kindly ask each and every /32 holder of the LISP-EID space to peer wherever possible with everyone without any discussion at every peering/connection point they are at. LISP-EID-wg are free to request this kind of things to make the experiment a success. ... not sure how well that are going down the throat of ISPs out there but isn't this an EXPERIMENT on the LISP protocol? I do support the idea behind the original LISP-EID-block request, but as the LastCall showed, there where to many unknown to let it move forward in that state. now I will sit back and let my suggestion be torn to pieces and see what we can end up with in the end :-) -- Roger Jorgensen | ROJO9-RIPE [email protected] | - IPv6 is The Key! http://www.jorgensen.no | [email protected] _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
