Subject: Difference between translation in LISP vs. Six/One Router -- Re: [RRG] Six/One Router Design Clarifications

From: Christian Vogt <[email-masked]>
Date: Tue, 29 Jul 2008 17:11:09 +0100

Dino,

you wrote:

> I implemented translation in LISP so I am not speculating. What you
> are doing in Six/One is no different than LISP.

No, the two are very different:  LISP translation requires *per-
session state*, whereas Six/One Router translation is *stateless*.

As a consequence of being stateful, LISP translation shares many of
the disadvantages of NATs, which Six/One Router avoids.

I am saying this based on the current specifications of LISP [1], its
translation extensions [2] (section 6), and Six/One Router [3].

Let's be more specific on (1) the reasons why LISP translation
requires state, (2) how Six/One Router avoids state, and (3) which
architectural disadvantages LISP has due to the stateful translation.

I will use the terms "LISP router" and "Six/One router" to describe
tunnel/translation routers in LISP and Six/One Router, respectively.

(1)  Why does LISP translation require state?

Two independent reasons why LISP routers need per-session state:

- EID multiplexing:  LISP routers multiplex a large set of EIDs onto a
   smaller set of locators.  They need the state to demultiplex a
   received locator back to the correct EID.

- Distinguish between tunneled and translated sessions:  To enable a
   transition path from translation to tunneling, hosts behind a LISP
   router must be reachable at both a locator and an EID:
   Correspondent hosts in legacy edge networks must contact a locator
   (via one LISP router), and correspondent hosts in upgraded edge
   networks should contact an EID (via two LISP routers).  The
   necessary implication of this is that correspondent hosts in
   upgraded edge networks will able to contact hosts in upgraded edge
   networks at two address types, locators and EIDs.  LISP routers
   must therefore be able to decide whether an egress packet exiting
   their edge network should be tunneled or translated.  This is
   important because the packet's source address, when eventually
   delivered to the correspondent host, will be different depending
   on whether the packet is tunneled or translated:  If the packet is
   tunnled, its source address will be an EID upon packet delivery.
   If the packet is translated, its source address will be a locator.

   LISP routers need state to decide whether an egress packet should be
   tunneled or translated, because the egress packet alone has
   insufficient information to make this decision.  This state must be
   per session.

   http://users.piuha.net/chvogt/misc/why-lisp-is-stateful.pdf

   The link above is to a slide that illustrates the need for state in
   LISP routers:  Host A, located in an upgraded edge network, can be
   reached at two addresses -- at an EID (ABC::1) via tunneling, or at
   a locator (1000::1) via translation.  Correspondent host B can use
   either address because it is also in an upgraded edge network.
   Independent of which address correspondent host B uses, the address
   seen by host A is EID ABC::1.  So return packets from host A to host
   B won't hold any information based on which the LISP router on host
   A's edge network could decide whether the return packets should be
   tunneled or translated.  Consequently, LISP routers must memorize
   whether a session is tunneled or translated at the time they receive
   the first ingress packet of that session.  This requires per-session
   state.

(2)  How does Six/One Router avoid state?

- Six/One routers do not multiplex multiple EIDs onto a single
   locator.  Hence no state is needed to demultiplex a received
   locator back onto the right EID:  The right EID can be
   unambiguously determined based on the received locator.

- Six/One routers do not need to decide whether packets should be
   tunneled or translated, because packets are always translated.
   How this translation is specifically performed is described in
   section 2.4 of [3].

(3)  Which architectural disadvantages does LISP have due to the
      stateful translation?

- Limited host reachability:  Since the locators that LISP translators
   are using for a given host are not stable (since they are
   allocated dynamically on an on-demand basis), it is difficult to
   reach these hosts.  You cannot place the locators in DNS.  (FWIW,
   the original NAT-PT had the same issue, and this was one of the
   reasons to deprecate it.)  Six/One Router provides unlimited host
   reachability because hosts have stable locators.

- Need for synchronization:  The LISP routers of a given edge network
   must synchronize their state in order to allow for fail-over and
   load balancing.  Without state synchronization, active sessions
   would break when handed over from one LISP router to another.
   Six/One routers don't have to be synchronized because they are
   stateless.

So much, so good.  Needless to say:  I'll be very happy to answer any
remaining questions, be it on this list, throughout the ongoing IETF
meeting, or later during the RRG session.  Don't hesitate to ask.

- Christian

[1] http://tools.ietf.org/html/draft-farinacci-lisp
[2] http://tools.ietf.org/html/draft-lewis-lisp-interworking
[3] http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf

--
to unsubscribe send a message to [email-masked] 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

---

From: David Meyer <[email-masked]>
Date: Tue, 29 Jul 2008 10:14:32 -0700

Christian,

> session state*, whereas Six/One Router translation is *stateless*.

	No, LISP translation does not require per-session
	state. I'm running one (www.translate.lis4.net), and it
	holds no per-session state. 

> the disadvantages of NATs, which Six/One Router avoids.

	LISP translation requires only local static configuration
	(if you want to call that state, but I don't think that's
	 what you're talking about).

	 Here is the config of www.translate.lisp4.net:

	  ip lisp translate inside 153.16.10.5 outside 128.223.157.65

	That's it. BTW, people have been pounding the web server
	on 153.16.10.5 and this is the state its holding:

titanium-dmm# sh ip lisp translate-cache 
LISP EID Translation Cache for VRF "default" - 1 entries
Inside: 153.16.10.5 outside: 128.223.157.65, ingress/egress count: 17936/183569 
titanium-dmm#  

	I'll talk a little about this at the GROW meeting, and 
	Darrel a transition talk at the EXPLISP BOF too.

	That said, translate (NAT) isn't the most scalable way to
	do this (it does have the advantage, shared with NAT, of
	being purely local). PTR is much more scalable.

	Dave

---

From: Christian Vogt <[email-masked]>
Date: Tue, 29 Jul 2008 18:40:52 +0100

David -

> 	holds no per-session state.

Then tell me how.

Do you reserve a separate IPv4 locator per IPv4 EID?

And how does the LISP router decide whether an egress packet should be  
tunneled or translated?  Does it uphold the invariant described in  
section 2.4.2 of the Six/One Router paper?

- Christian

---

From: David Meyer <[email-masked]>
Date: Tue, 29 Jul 2008 11:11:51 -0700

> Do you reserve a separate IPv4 locator per IPv4 EID?

	Well, in this case yes. In this case, that is what we
	decided to deploy, and to be practical, it does the job
	it was designed to do (and quite well, as you see).

> section 2.4.2 of the Six/One Router paper?

	So with this config:

	If the packet comes from the outside and is destined for
	the "outside" address (128.223.157.65), the desination
	addresses is translated to the "inside" (153.16.10.5)
	address. If the packet comes from the inside and its
	source address is the "inside" address (153.16.10.5), the
	source address is translated to the "outside" address
	(128.223.157.65).

	Simple as that.

	Dave

---

From: Scott Brim <[email-masked]>
Date: Wed, 30 Jul 2008 08:52:59 +0100

> 	Well, in this case yes. 

I believe that's also what the Six/One router does, correct?

Scott

---

From: Christian Vogt <[email-masked]>
Date: Wed, 30 Jul 2008 12:47:58 +0100

> I believe that's also what the Six/One router does, correct?

Right.  And I am assuming that, in order to be stateless, you need to
use even more from Six/One Router.  Either the techniques from section
2.4 in the Six/One Router design paper [1], or one of the alternative
techniques [2] that I had explained on this mailing list in May.

I am simply curious which of these techniques you are using, or if you
came up with something new.  The LISP documents don't give the answer.

- Christian

[1] http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf
[2] http://psg.com/lists/rrg/2008/msg01279.html