Short version: Ran objects to some things I wrote about his ILNP
protocol - which was chosen in preference to the LISP
protocol, IRON, Ivip and many others by the IRTF
Routing Research Group co-chairs as their recommended
scalable routing protocol for further IETF development
(RFC-6115).
However, he does not mention what statements he
disagrees with. He simply refers readers to a bunch of
papers and some Internet Drafts at his site.
Below is a list of things I wrote about ILNP and why I
wrote them.
Hi Ran,
In the thread "Re: The death John McCarthy - LISP, HIP & GSE" you wrote:
Gentle Folks,
Robin Whittle either hasn't read the ILNP documents
and published papers or he hasn't understood them.
His characterisation of ILNP on this list is
not correct in a wide range of dimensions. Folks
who want to learn more about ILNP might consider
starting at this web site:
<http://ilnp.cs.st-andrews.ac.uk>
I'm not a LISP or HIP expert or spokesperson,
but I also doubt that his characterisations
of LISP or HIP are correct.
Yours,
Ran
This is all very broad-brush, as if you are too busy to help IETF list
people understand exactly which statements about ILNP you dispute.
Likewise you don't help the readers by directing them to any particular
documents at your site. I recall that many of your messages to the IRTF
Routing Research Group list were of a similar form.
In recent IETF list messages I have characterised ILNP as:
0 - A member of the Locator-Identifier Separation class of
scalable routing protocols.
and the following I wrote about all Loc-ID Separation protocols:
1 - They are IPv6-only.
2 - They require rewritten stacks and applications.
3 - They require hosts to send and receive more packets and do
more work (than the current arrangements) in order to respond to
a communication, when (as is often the case) it is important that
the reply packet must go to no other host than the one which has
the Identity specified as the source in the initiating packet.
4 - They can't support mobility with MNs behind NAT or handle Loc
changes fast enough for VoIP.
If there is something else I wrote which you object to, please write
about it to the list. Likewise regarding any specific disagreements you
have with what I wrote about the LISP protocol and HIP.
Point 3 above is a critique of ILNP, HIP and GSE - or any other protocol
which I regard as being of the "Locator-Identifier Separation" class
(this does not include the LISP protocol). I argue that such protocols
impose extra burdens of work, delays and extra packets going in and out
of a host which responds to an incoming communication initiation in a
way which requires its response not to be delivered to any host which
does not have the Identity specified in the sender field of the
initiating packet. That's a rather long sentence, but it means that the
simple process we have with today's "Loc-ID overloaded IP address"
arrangement - of responding to the initiating packet's source IP address
- is something which sometimes, probably frequently, can't be done with
Loc-ID Separation.
If a host ABC receives a communication request with the IP address
XYZ in the source field (which in today's "overloaded" arrangement
acts as both a host/endpoint Identifier and routing Locator) then
ABC can send a reply packet straight back to the XYZ IP address
without doing any lookups, knowing that the routing system will
either deliver it to the host which has this IP address (or to one of
multiple hosts, in the case of anycast) - or the packet will be
dropped.
So ABC can craft its reply with whatever information it wants host
XYZ to have, but would not want any other host to have - and send it
to IP address XYZ.
This is still true if, as is possible, the source address of the
initiating packet is spoofed.
So in the current "overloaded" arrangement, a host can respond
immediately and without any lookups.
With Loc-ID Separation, to achieve the same assurance, ABC would need
to do a mapping lookup of the Identifier which came in the initiating
packet, and send the reply to one of the resulting Locators (assuming
the Identifier was for a multi-homed host, meaning there would be at
least two Locators). This requires sending at least one packet to
the global mapping system, which after some delay (due to its global
geographic size, and due to the need for real-time non-cached
responses forcing it to get a response from the one or one of a few
authoritative query servers) would return a single packet of mapping
information to ABC, with the Locators and some other stuff regarding
which one to choose in preference to the others. (Maybe the mapping
would be too long for the and would need to go in two packets - or
maybe it would be sent as a long packet in IPv6, which was too long
for some part of the path near ABC, and so it would be dropped
with a packet-to-big response, causing the query server to send the
same information again in shorter packets - assuming the query server
cached its response for this purpose.)
Assuming the map reply packet arrives, then ABC can proceed to send a
reply to XYZ, knowing it will get to XYZ or be dropped (and therefore
will not to to any host other than XYZ), by sending the packet to one
of the specified Locators. If the mapping query or response packet
gets lost, ABC will need to wait two or so seconds to send a second
query.
This is bad enough for a host in a data centre. It is much worse for
a host ABC hanging off a possibly low data-rate, expensive,
high-latency high packet loss mobile radio link such as 3G or
whatever.
So my critique of Locator-Identifier Protocols is also of one of the
longest cherished wishes of quite a few IETF people, from the early 80s
to this day. An early write-up of this wish is in RFC-1498, which was
originally written in 1982.
I wrote about this on the RRG list (2010-06-22):
"Overloading" of Loc & ID functions is good for hosts and should be
maintained
http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html
in response to something you wrote in an earlier message:
RA> If we ignore the lack of 40 years since the initial definition
> of IP itself, I believe there is actually pretty broad consensus,
> both within this RG, and also within the routing/addressing parts
> of the IETF, that the current overloaded semantics are indeed
> the root of multiple problems.
but you never responded. Toni Stoev replied and in messages 07022, 25,
27, 29 and 30 we discussed his proposal - but I couldn't envisage a
fast, lightweight, secure way of doing it.
RW> Toni hasn't yet described a secure method by which
> one node can tell another it has a new Locator.
>
> I can't imagine how this proposal, or any other CEE
> (Loc/ID Separation) architecture, such as ILNP,
> could handle mobility with sufficiently short
> delays and sufficiently light-weight protocols
> to make it practical or attractive for VoIP.
>
> If a scalable routing proposal can't do mobility
> with delays short enough to not disrupt conversations
> with VoIP, then I think it is a non-starter. So far
> I think TTR Mobility is the only approach to mobility
> which can do this - and it is only for CES
> architectures such as LISP, Ivip and perhaps IRON.
Here are the reasons why I wrote these things about ILNP.
0 - Quoting from http://tools.ietf.org/html/draft-rja-ilnp-intro-11
"The crux of this proposal is to have different names for the
identity of a node and the location of its subnet, with crisp
semantics for each. This enhances the Internet Architecture
by adding crisp and clear semantics for the Identifier and
for the Locator, removing the semantically-muddled concept
of the IP address, and updating end system protocols slightly,
without requiring router changes."
Throughout the document, the term "the Identifier/Locator split
mode (of operation)" is used to refer to the use of ILNP.
So I assume you agree with me that ILNP is a Locator-Identifier
Separation (AKA "Split") protocol.
1 - ILNPv6 has a 64 bit Identifier - the lower order bits of the
field currently known as the 128 bit IP address - so there's no
need for a new packet format. In ILNPv4 the 32 bit IP addresses
become Locators and a new packet format is required to carry 64 bit
Identifiers:
"The obvious two ways to carry the ILNP Identifier with
ILNPv4 are either as an IPv4 Option or as an IPv6-style
Extension Header placed after the IPv4 header and before
the upper-layer protocol (e.g. OSPF, TCP, UDP, SCTP)."
"At least some currently available IPv4 forwarding silicon
is able to parse past IPv4 options to examine the upper-
layer protocol header at wire-speed on reasonably fast
(e.g. 1 Gbps or better) network interfaces. By contrast,
no existing silicon is able to parse past a new Extension
Header at all. So, for engineering reasons, ILNPv4 uses
a new IPv4 Option to carry the Identifier values."
HIP and GSE are applicable to IPv6 only. I argue that ILNPv4
is so impractical as not to be considered realistic, because
some, most or all routers in the DFZ handle packets with IPv4
options via their "slow path" - with the CPU rather than the
fast forwarding hardware. I have no knowledge of this directly
but it was discussed on the RRG and people who I assume do have
direct knowledge of this agreed. See RRG msg06001 and:
End-to-end measurements on performance penalties of IPv4 options
Fransson, P.; Jonsson, A.
Global Telecommunications Conference, 2004. GLOBECOM apos;04. IEEE
Volume 3, Issue , 29 Nov.-3 Dec. 2004 Page(s): 1441 - 1447 Vol.3
10.1109/GLOCOM.2004.1378221
http://www.sm.luth.se/csee/csn/publications/end_to_end_measurements.pdf
The abstract concludes:
"From the analysis it can be concluded that there is a slight
increase in delay and jitter and a severe increase in loss rate."
If you have any evidence that most or all routers in the DFZ and
in edge networks can handle IPv4 packets with novel options at
full line rate, without excessive losses or delays, please present
it. If this was so, then it would greatly expand the possibilities
of what can be done with the IPv4 Internet.
2 - GSE and HIP require existing IPv6 applications to be rewritten.
Section 9.1 of draft-rja-ilnp-intro-11 claims (to my understanding)
that a host with an ILNP stack will perform ILNP communications with
today's IPv6 applications:
The existing BSD Sockets API can continue to be used with
ILNP underneath the API. That API can be implemented in a
manner that hides the underlying protocol changes from the
applications.
For a long while, I and I think other RRG folks - co-chair and
ILNP supporter Tony Li included - accepted this notion that ILNP
could work without the need to rewrite IPv6 applications. I think
this was regarded as a major feature of ILNP over any other Loc-ID
Separation protocol.
When I tried to figure out how this would work, I couldn't find
a way. You didn't respond to my requests for guidance. Tony had
a go at it, gave up (it was late) and never tried again:
http://www.ietf.org/mail-archive/web/rrg/current/msg07113.html
Before giving up, he wrote (msg07111):
And having a name oriented stack would be the best solution.
ILNP is not a name oriented stack protocol - and any such protocol
would require rewritten applications.
3 - As mentioned above with the host ABC and XYZ discussion.
4 - Loc-ID Separation protocols (Core-Edge Elimination protocols)
implement mobility by the Mobile Node (MN) getting a new IP address
(Locator) and securely updating the global mapping system with
this new Locator. Either the MN or the global mapping system then
needs to update the mapping stored by any hosts they are currently
communicating with.
To do this securely will take more time than is acceptable for VoIP.
Since a MN may gain new Locators frequently - for instance just for
a few seconds when coming into range of a WiFi system which is
preferable to a 3G connection, the flurry of mapping updates to
the potentially numerous correspondent hosts becomes unreasonably
expensive.
The LISP protocol's approach to mobility has the same problem,
though it is not a Loc-ID Separation protocol.
As far as I know, the only way of doing mobility without needing to
instantly update the mapping of all the correspondent hosts is my
TTR Mobility system, which can be applied to Ivip or LISP, and which
I understand is used, in principle, for all communications (mobile
and non-mobile networks) in Fred Templin's IRON.
http://www.firstpr.com.au/ip/ivip/#mobile
The correspondent hosts have mapping to a (typically close
to the MN) ITR-like router I call a Translating Tunnel
Router. The MN establishes 2-way tunnels to one or more TTRs
from each of its potentially multiple IP addresses, which can
be behind any number of layers of NAT. As these change, and
as the best one to use changes, this is just a matter between
the MN and the TTR which is currently receiving all the
incoming packets from the correspondent hosts.
Loc-ID Separation protocols can't work with the host behind NAT.
That's fine when the protocol is used for the IPv6 Internet, but
not for IPv4.
- Robin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf