> Well spoken. Again, after the short late-night email, because: Since you were subjective on your comments I will be direct and to the point in my responses. But only direct to your comments that are clear.
> 1) There is a long list of deficiencies which LISP maintains and which are > due to clinging to > paradigms like prefix building, DiffServ Do you mean map-cache caching. I don't know what you mean by prefix building. EID-prefixes are assigned to LISP sites just like prefixes are assigned today. There is no operational difference. > bottom line "no interest in knowing the traffic outside/beyond the packets' > incoming waiting queues",etc.etc. > (I don't want to repeat it here) Diffswev code points are copied to the outer header. And we have seen cases where carrier-in-carrier scenarios, it is a feature to hide such code points. > 2) LISP specifics: > a) Its structures are fixed though not even an idea is cast how to form > and handle Multicast- and Anycast-Locators. Not true. Both EID and Locator address formats are flexibly encoded. We have seen use-cases where EIDs could be used as Fedex tracking numbers or VIN numbers (Vehicle ID Numbers). And we have seen Locators encoded as multi-tuple addresses that include Geo-Coordinates. > Anycast services (nearest hospital, nearest rescuer, nearest parking > lot, nearest gas station, etc.) aren't considered at all. An EID can be used as an anycast address where the database lookup can decide which locators to return. And Locators can be anycast addresses as well to encapsulate packets to the closest locator. Nothing needs to be designed in the protocol to make this happen. > Most of the anycast services have to be scoped (it makes no sense to > disseminate "I am an empty parking lot in Munich." all over Germany/world) Since LISP uses a pull database, there is no dissemination in the mapping system. Anyone that wants to talk to the EID will need to cache the locators but only in those locations. > and I doubt that LISP-PULL fits in. Also: By dealing only with > unicast, LISP does not provide and bits to differentiate between unicast, > multicast,... Because the existing semantics are used. Class D encodings for IPv4 and first-byte 0xFF for IPv6. > b) GRE-tunnel nesting is a great bail out. A new concept however > should try to avoid it as much as possible .LISP however prefers > LISP-header nesting rather than enlisting transits inside of ONE > extended LISP-header. LISP does re-encapsulating tunnels as well. See definition of RTRs in the TE and NAT-traversal Internet Drafts. > 3) LISP-DDT specific: > It will kill IPv4 and I honestly think about writing to the IESG and > explain to the IESG why, and why this is not just a bug that can be repaired > whithin This makes no sense. Why would it kill IPv4 and not IPv6? DDT uses the iterative lookup model that DNS uses. Those properties are well known and we have a lot of experience with them. > LISP-DDT. Here only this: At first I thought LISP-DDT is doomed to fail, > but being the coffin nail for IPv4 is the alternate and even worse > consequence. Can you back the claim up with some data and technical commentary. If you do, I would be glad to continue this thread. Dino > > > 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 > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
