On the other hand Joel it could be said that you are reading a lot into white spaces without clear rationale. The regionality in the RIR structure has nothing to do with the regionality or, more relevantly, the lack thereof, in routing BGP, LISP or HELLO for that matter. So, for me, your comment does not appear to make much sense in this context.
Mine, Geoff On 10/01/2013, at 8:37 AM, Joel M. Halpern <[email protected]> wrote: > And this gets to the reason why specifying the allocation policy will take a > lot longer. > From what I understand of LISP, and speaking only as an individual > participant, it is not at all obvious tome that the RIRs have an inherent > role in LISP EID allocation. LISP EIDs are not regional in any meaningful > sense. > > Note: Assuming we do create some mechanism for allocation, with multiple > players, and assuming the thier members wanted them to, there is no reason > that the RIRs could not choose to have a role. I have no desire or ability > to prevent them. I just seen no reason to wire it in. > > Yours, > Joel > > On 1/9/2013 4:02 PM, Roger Jørgensen wrote: >> 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 :-) >> > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 [email protected] _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
