On Thu, Jan 10, 2013 at 9:17 AM, SM <[email protected]> wrote: > At 13:02 09-01-2013, Roger Jørgensen wrote: >> >> 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. > > > I'll make the counter-arguments.
excellent!:-) >> * 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. > > > This would be a long-lived experiment. It rarely works well in practice as > the people who set it up might not be there to clean up the mess. It's not > a huge problem to ask for some IP address space to reserved. I am ignoring > a few details which might point to that being a problem. I agree, in practice this happen too often, which is why I suggest this feature should be labeled EXPERIMENTAL but stable, or something similiar and explain why. That can also hurt deployment so we have to be very very clear on what we mean with EXPERIMENTAL here. > The "if someone needs more space" makes it a IP address allocation problem. > Someone will have to deal with that request. The IETF does not do that. I > pointed to "operational models" in an unrelated draft so that people can > have at least a little information about the options and decide which option > they prefer. I prefer to avoid a 6to4 scenario as making anything historic > is a recipe for debate. I don't like legacy space because I am creating a > problem for someone else to sort out. In the beggining only a limited piece of that reserved /12 will be used, if we divide it into regions or not that's no big deal, point being it's limited affect on the _global_ routing table since those /32 will have to be announced there. I mention RIR regions to get some geographical diversity in the experiment, not being EU/US region alone. And about handing out those /32, there will be a set of guidelines telling the RIR/entinty managing this in practice on how they should deal with it, in all practical matter the LISP-EID-wg will have to decide on which ISP should be let into the experiment now in the begging to make sure we actual get an experiment. Also - only a limited part of the /12 will be used, if that space are empty within lets say 5 years I will claim this being a success and at which point LISP-EID-wg/LISP-wg need to a discussion and decide, should the restriction being removed or should we call this experiment a failure. In the end it's IETF that will have to "approve" it. > At 13:37 09-01-2013, Joel M. Halpern wrote: <snip> > >> 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. > > > The reality is that RIRs are currently managing IPv6 address allocations. > It does not bother me if IETF participants decide to give some other entity > the responsibility to do the work as long as there is a clear explanation. I think we should use the RIRs as long as it's possible, but of course, this space LISP work in general do question how the future should be. BUT that's an ENTIRELY different discussion. Right now we're using the tools and functions available out there and it would be stupid to not relay on and reuse the experience and knowledge sitting within the RIR community. > It is a lot of work to do an analysis of the various alternatives and figure > out the better alternative. The proposal made by Roger Jørgensen is a step > forward. Geoff Huston explained some stuff. I think that his comments may > have been misunderstood. Brian Carpenter pointed to some interesting > operational questions that have been raised or implied. I may be missing > them as I don't have a clear sense of how the working group wants LISP to > work. That's a excellent point, how do we want LISP to work... I think I understand it but I have no problem to see that it's unclear. I guess that's a direct request to this WG, make sure that part is communicated better. However, it's still in the early phase of the protocol so understandable that it's unclear to. -- 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
