Well spoken. Again, after the short late-night email, because:
1) There is a long list of deficiencies which LISP maintains and which are due
to clinging to
paradigms like prefix building, DiffServ 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)
2) LISP specifics:
a) Its structures are fixed though not even an idea is cast how to form and
handle Multicast- and Anycast-Locators.
Anycast services (nearest hospital, nearest rescuer, nearest parking
lot, nearest gas station, etc.) aren't considered at all.
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)
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,...
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.
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
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.
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
