[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] LISP and IP Interworking - Anycast PTRs == Ivip
Hi Darrel,
Thanks for posting this text, which I assume will become an ID soon.
In recent months there have been various on-list references to LISP
"Proxy Tunnel Routers" for ensuring sites without ITRs can send
packets to hosts with LISP-mapped (EID) addresses. There has also
been discussion of using "NAT" for this purpose.
Now we have a full description of these two approaches:
http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt
Your LISP "Proxy Tunnel Router" approach is in principle, and in
most details, identical to the "Anycast ITRs in the core" idea I
posted to the RAM list over five months ago (2007-06-15).
http://www1.ietf.org/mail-archive/web/ram/current/msg01518.html
That was within 24 hours of me thinking of the idea - which has
proven to be useful and novel - at least in terms of what is in IDs,
list messages etc.
The on-list and private responses I received in June from some LISP
folks was unsympathetic - there was no encouragement or
constructive criticism. I was urged - by LISP and non-LISP folks
alike - to write an ID. A month later I produced:
http://tools.ietf.org/html/draft-whittle-ivip-arch-00
Since then, this ID seems to have been ignored by LISP people.
There is much more to Ivip than "anycast ITRs in the core", but that
was the starting point which prompted me to develop some new ideas.
Eliot developed a similar "anycast ITRs in the core" approach for
LISP-NERD. It seems, from the language with which he expressed his
ideas, that he developed this independently of whatever he might
have known about Ivip. He acknowledged that his approach resembles
mine:
http://psg.com/lists/rrg/2007/msg00260.html
http://psg.com/lists/rrg/2007/msg00264.html
http://psg.com/lists/rrg/2007/msg00288.html
Your new lisp-interworking-00.txt doesn't mention Ivip or my
proposal of this approach in mid-June.
There are two reasons why I think your new ID should explicitly
acknowledge the similarity between "Proxy Tunnel Routers" and Ivip -
even if you developed PTRs completely independently of anything I wrote.
Firstly, it seems I was the first to propose this arrangement in a
public document or mailing list message.
Secondly and more importantly, I believe you should assist readers
in understanding the various ITR-ETR proposals by pointing out what
goals, mechanisms and outcomes your proposal shares with other
proposals, and how it differs.
There is a whole section in the Ivip ID - over 5 pages - devoted to
showing how Ivip and LISP differ, and what they have in common.
Incremental deployability has always been a fundamental requirement
of any ITR-ETR scheme.
At the start of December, LISP finally gained a mechanism which
enables it to be incrementally deployable. The IDs are:
http://tools.ietf.org/html/draft-farinacci-lisp-05 (43pp)
http://tools.ietf.org/html/draft-lear-lisp-nerd-02 (29pp)
http://tools.ietf.org/html/draft-meyer-lisp-cons-03 (21pp)
http://tools.ietf.org/html/draft-fuller-lisp-alt-01 (17pp)
http://tools.ietf.org/html/draft-curran-lisp-emacs-00 (9pp)
http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt(13pp)
These 132 pages are longer than Ivip's 105 - or 116 including IPTM.
Is there some kind of inverse relationship between funding and
output in this field?
ist-RiNG has lots of money. So far it has produced no technical
documents and no discussion.
Apart from John Curran, who works for servervault.com, and Noel
Chiappa, who is is an independent researcher - as I am - LISP
authors all work for Cisco Systems. I assume you folks at Cisco are
doing at least some of your LISP work as part of your paid
employment - yet it took you longer to create an incrementally
deployable ITR-ETR scheme than it took me. At the very least, I
assume Cisco sometimes flies you to IETF and other meetings where
you can pursue LISP work.
I don't work on Ivip or RRG correspondence in my employer's time.
I am self employed and it costs me lost income to do this stuff.
Yet my results come sooner - and I think they are easy to read and
understand.
I request anyone who is seriously interested in ITR-ETR schemes to
read the Ivip ID, Fred's sprite-mtu work, my IPTM work:
http://www.firstpr.com.au/ip/ivip/pmtud-frag/
and the recent excellent discussion between Fred and me on this
list. All ITR-ETR schemes need a solution for the PMTUD and
fragmentation problem. I have read nothing substantial from the
LISP team on how to solve this.
Then, please provide critiques, alternative ideas, reports of
difficulty in understanding etc. on-list or privately.
I found your new ID generally easier to read than the earlier LISP
IDs. The examples were particularly helpful. However, I suggest
you use terminology indicating explicit packet flow direction rather
than "talk to" and "speaking to".
Here is a critique of LISP-NAT, based on my potentially faulty
understanding.
1 - LISP-NAT does not solve the problem which "(typically)
Anycast ITRs in the Core" (Ivip, LISP PTR) does - the
problem of how a host in a site with no ITR can send a
packet to a host with a LISP-mapped address (EID) and
have that packet delivered properly - that is, via an
ITR which tunnels it to the correct ETR. This problem exists
irrespective of whether the ordinary host or the host with
the LISP-mapped (EID) address initiates a two-way
communication. The Net needs to work for single, isolated,
packets.
LISP-NAT only helps in a two-way communication session - and
then only when the host with the LISP-mapped (EID) address
initiates this session.
2 - The LISP-NAT device can only do its work for as many
concurrently active hosts with LISP-mapped (EID)
addresses as the device has "publicly routable" IP addresses.
These "publicly routable" addresses are either ordinary
addresses, for exclusive use for this LISP-NAT purpose,
or they are a curious thing - "LISP-R" addresses.
As I understand it, a "LISP-R" address is a LISP-mapped address
(an EID - an address such that an ITR handling a packet
addressed to this address would encapsulate the packet and
tunnel it to a specific ETR close to the destination host
which actually has this address) *and* which is also part of
an advertised BGP prefix and reachable via ordinary BGP
router forwarding. This means, I think, that this address
is not covered by PTRs which advertise the prefix which it
is within. This means that there are two ways a packet
could get to the router which handles this LISP-R address.
Firstly, it could originate in a site with a LISP ITR, which
would tunnel the packet to the ETR (presumably the same
router which is responsible for this address).
Secondly, if the packet originates in a host in a site with
no LISP ITR, it arrives by ordinary forwarding through the
BGP router system.
As such, the use of LISP-R address space seems to introduce
complexities and limitations which make it unsuitable for
robust multihoming, or portability between ISPs.
3 - Therefore, LISP-NAT provides no multihoming, portability etc.
benefits, for the packets coming from the host in the site with
no ITR - while "Anycast ITRs in the Core" (Ivip, LISP PTR)
provides all these the benefits.
4 - It is not clear how long the NAT-ITR should maintain the
association between the LISP-mapped host's address and the
LISP-R address in the translation pool. If there is a pause
in activity, the communicating hosts reasonably expect to be
able to send packets to each other in the future. But unless
the NAT-ITR has as many LISP-R addresses in its pool as it has
LISP-mapped host addresses, it will have to recycle the pool
addresses at some point in time, with the risk that a remote
host will send a packet to a pool address which has now been
associated with a different LISP-mapped host than the one
it was previously communicating with.
If these criticisms are valid, I believe the ID should explicitly
convey these limitations to the reader in some way.
I thought section 2 (LISP Internetworking Models) was systematic and
well written. However, it left me with the impression that both the
PTR and the LISP-NAT would solve the problem you identified:
The most challenging case, case 4, occurs when a host at
a non-LISP source site sends a packet to a host in a LISP
site. If the source host chooses a non-routable EID address,
the packet continue to be forwarded (inside the domain) until
it reaches a router which cannot forward it, at which point
the packet is dropped. So either the EID that the
destination site is making available for other sites is
routed outside of LISP or an alternate mechanisms need to be
in place to solve this.
This specification describes two alternate interworking
mechanisms, Proxy Tunnel Router (PTR) (Section 5) and LISP-NAT
(Section 6).
In fact, LISP-NAT only works in a two-way communication is initiated
by a host with a LISP-mapped address, and then only by using a
separate range of addresses which must be in an ordinary BGP prefix.
Below are some typos which I think would be good to correct.
- Robin
Page 7
... on behalf LISP sites to non-LISP sites can reach ...
... on behalf of LISP sites so non-LISP sites can reach ...
Rather than deploying PTRs close the LISP sites, they get
deployed close to the non-LISP sites.
Rather than deploying PTRs close to the LISP sites, they are
deployed close to the non-LISP sites.
I didn't understand the term "scoping".
Page 8
Two instances of "140.1.1.1" should be "140.0.0.1".
4. The PE has route to ....
4. The PE has a route to ....
Page 9
in order to have a course way to control ...
in order to have a coarse way to control ...
There are several that a network using PTRs would place the
PTR as close as possible to non-LISP sites.
Perhaps:
There are several (burdens/impacts) that a network using PTRs
would place on the PTR ....
but then the rest of it doesn't make sense to me.
traffic will be routed towards ... (extra newlines)
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg