Well spoken.
Heiner -----Ursprüngliche Mitteilung----- Von: Geoff Huston <[email protected]> An: Luigi Iannone <[email protected]> Cc: LISP mailing list list <[email protected]> Verschickt: Mi, 9 Jan 2013 9:57 pm Betreff: Re: [lisp] draft-ietf-lisp-eid-block-03.txt back in workgroup On 09/01/2013, at 11:02 PM, Luigi Iannone <[email protected]> wrote: > Hi Geoff, > > On 8 Jan. 2013, at 20:21 , Geoff Huston <[email protected]> wrote: > >> >> On 08/01/2013, at 9:34 PM, SM <[email protected]> wrote: >> >>> Hi Terry, >>> At 22:03 07-01-2013, Terry Manderson wrote: >>>> 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? >>> >>> The work item seems useful. >>> >>>> 2) If so, what direction should the WG take this document so that the LISP >>>> experiment is best served? >>> >>> The problem is justifying the IP address space allocation and explaining >>> how it will be managed. >>> >>> My guess is that the working group took an ORCHID approach (copy and paste :-)). I suggest dropping the idea of calling it a very large-scale experiment. The unstated problem is about politics. I suggest taking a look at draft-lear-lisp-nerd-09. It contains a good discussion of operational models and the trade-offs. >>> >> >> I was on the IAB at the time that ORCHID was being considered - the issue there was to find a balance between enough bits for acceptable crypto and basic conservatism in the absolute size of the request - at the time a /28 appeared to be a suitable compromise considering that this was an experiment. >> >> Given that this is an experiment and that the transition from experiment to widespread deployment may well entail renumbering (as was the case with the 6bone) then one approach may well be to use a modest prefix that has a limited capacity that would force renumbering in the shift from experiment to widespread adoption, if such occurs in the future. >> > > I may be mistake but I do not see the renumbering need in the LISP case. It all depends on the philosophy behind experimental allocations. If we were to assume that each and every single experiment in IPv6, including all forms of cryptographically generated addresses, all forms of transitional mechanisms, all forms of address plans and all forms of routing experiments were each to request an experimental allocation that was "once and forever" and assumed at the outset that the experiment would result in comprehensive deployment over a network many many times larger than today's then I hope you can appreciate that we'd not have enough space to accommodate each and every experiment's requirements in the IPv6 space. So the conventional philosophy behind experimental allocations is to use enough space to allow the experiment to operate and to gain experience with the technology. If this proves to be useful and taken up by the industry (and of course this process involves is by no means an assured outcome - quite the opposite in fact) then its again conventional to look at how to support the technology within the existing token distribution framework, or whether its appropriate to make changes to the token distribution framework. Now obviously some proponents of every experiment see universal adoption of their particular technology as a given, including some LISP proponents no doubt. So of course we see many (most?) experiment proponents proudly proclaim that they are uniquely different and obviously their particular experiment will naturally result in universal deployment, so why not assume that happy outcome at the outset of the experiment and allocate resources at a scale commensurate w ith their no doubt certain universal deployment in the not-so-distant future? But wishing it, no matter how enthusiastic you may be personally, does not make it so. A prudent approach in a space that has seen, and is likely to see, many experiments proposed, is generally to provision resources to conduct the experiment at the scale of the experiment and if the experiment leads to someplace positive then look at what is required if the technology is to head to larger levels of deployment. > The prefix request was written in such a way to reduce renumbering, rather making the prefix "bigger" so to accommodate the growth. This would also be an easy change, rather then adding different prefix blocks just change the length of the existing prefix. I am continually confused by the assumptions behind this assertion, and I've heard this assumption a number of times in the course of the consideration of this draft. If LISP is so fragile that it requires a very particular deployed address structure in order to operate, then frankly we could do precisely the same in BGP and achieve better results because of avoidance of tunnelling. I find it somewhat strange to see this adamant view that LISP absolutely requires a uniquely structured address plan in order to achieve any useful outcome in terms of scalable routing, at a cost of increased latency and exposure to vagaries of tunnel behaviour, while at the same time ignoring the simple observation that if one were to do the same surgery on the address plan in BGP the outcomes would likely to be just as good if not better, without the negative factors of map-resolution-related latency and tunnelling. > > I think this is something to keep in the future document(s). And I strongly disagree with your opinion. If we did this for every experiment that we encounter that proposes some unique address plan that is intended to improve security, routing scaleability, auto-configuration, pre-provisioning, network virtualization, software programability, etc etc, then once more we are going to find ourselves contemplating address exhaustion in IPv6 far sooner than anyone would've rationally anticipated. Geoff _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
