Dino,
As you can see, I have chosen a peaceful and neutral subject line. See below my
comments.
Heiner
-----Ursprüngliche Mitteilung-----
Von: Dino Farinacci <farina...@gmail.com>
An: heinerhummel <heinerhum...@aol.com>
Cc: gih <g...@apnic.net>; ggx <g...@gigix.net>; lisp <lisp@ietf.org>
Verschickt: Sa, 12 Jan 2013 10:11 pm
Betreff: Re: [lisp] draft-ietf-lisp-eid-block-03.txt back in workgroup
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.
HH: I mean using prefixes AT ALL !!!: I know this is state of art in
classical internet routing. LISP-TARA (yes, TARA is a loc-id-split solution)
would reduce it be the same degree by which TARA routers were deployed. After
all, you can't use prefixes for multicast or anycast either. As far as I know
IPv4- FIBs don't have any entries for multicast or anycast.
Do you know whether IPv6 has a multicast-FIB and/or an anycast-FIB ? My guess
is NO. Instead I believe that this is another IETF-law that there is only 1 FIB
:-(
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.
HH: I am accusing the DiffServ philosophy, which was once a counter movement to
IntServ where available bandwidth capacities played a major role.
The DiffServ philosophy prevented that ideas were cast to make routers aware
of the traffic in the near surrounding and to deal with it - even without
connections a la SVC or LSP..
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.
HH:
Does your database ask back "where are you, user, so that I can send you the
right locator "?
By your description that database is an anycast server .
Do you envision that the users are mobile and will repeat their query every now
and then ? Don't you be afraid of bottle necks ?
Note, one aspect of the scalability was the update churn. Your PULL solution
will create query churns to few (how few?) such databases. This will hamper
the general
operability of the internet itself.
An anycast service typically needs a scope (see mentioned examples above). The
areas your databases are responsible for won't comply with the area any
particular anycast service is limited to. In short: it doesn't fit at all!
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.
HH:Why so shy? You have a brand new (LISP) header and can do what you want and
should be interested in fast forwarding. There is unicast, multicast, anycast,
mp2mp, mp2p and broadcast to be differentiated. That could be done better than
by address range differentiation
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.
HH: Sure, but there are cases (detours) where employing a list of transit nodes
is simpler than multiple pairs of ITR and ETR .
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
HH:
Dino, your original LISP envisioned several versions: LISP2.0 using DNS and
others, one of which then became the preferred one.
Many years have passed and we now encounter not only the scalability problem
but also the ipv4 unicast address depletion problem.
The honorable intention of LISP was to support IPv4 rather than to pull over to
IPv6. I am sure you agree.
(IPv6 has so much address space, enough to address fractions of any square inch
of the globe, i.e. could esily encompass any locator info. But, I think,
neglecting ipv4 would be irresponsible. I am sure you agree again.)
LOC-ID-SPLIT not only meant "routing based on the locator to the egress-site"
but also
to identify any host by the info-doublet {ID=ipv4 address ; LOC= locator} in a
globally unique way, in case the iPv4 address by itself cannot be globally
unique anymore due to the ipv4 unicast address depletion problem.
Put in different words: the ipv4 address of any host must (only) be unique per
that site which is indicated by the respective locator.
(1)Provided that this is still a basic assumption of the LISP-group I conclude:
LISP-DDT will fail for sure.
(2)Provided that LISP expects that there cannot be any further hosts with IPv4
addresses after all ipv4 unicast addresses are used up I conclude: LISP-DDT
kills IPv4.
Why:
It is a MUST to get the info-doublet {ID=ipv4 address ; LOC= locator} by one
single query !!! Period.!!!
Analogous example:
Imagine, you have to write a letter to Mr. Li (there are about 20 million
people with this name), you only write this name on the envelope and ask the
officer at your (ingress) post office to add the address of Mr. Li all by
himself/herself (because he/she might have a database with all addresses of
all persons in the world - btw which of course is not true). Facit: That
cannot work !!!
Hence:
The FQDN must be converted to {ID=ipv4 address ; LOC= locator} by one single
query, i.e. must be done by the host itself, i.e. the host must prepend the
LISP header ! Eventually the ingress router might intercept the DNS-query and
act as a proxy, but even if so, the query must be sent to the DNS and to no
other database !
Sorry Dino, your defending DDT (how much better it is compared to LISP2.0
(DNS) couldn't convince me at all.
Heiner
-----Ursprüngliche Mitteilung-----
Von: Geoff Huston <g...@apnic.net>
An: Luigi Iannone <g...@gigix.net>
Cc: LISP mailing list list <lisp@ietf.org>
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 <g...@gigix.net> wrote:
> Hi Geoff,
>
> On 8 Jan. 2013, at 20:21 , Geoff Huston <g...@apnic.net> wrote:
>
>>
>> On 08/01/2013, at 9:34 PM, SM <s...@resistor.net> 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
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
