Subject: [lisp] Is LISP specifying a mechanizm to encapsulate an outer IP header over IP frame?

From: Linda Dunbar <[email-masked]>
Date: Tue, 05 Oct 2010 19:50:37 -0500

Reading through the "draft-ietf-list-08", I get the impression that LISP is
very much like IEEE802.1ah MAC-in-MAC, i.e. specifying a mechanism for a
gateway router (i.e. ITR) to encapsulate an outer IP header over an IP data
frame and ETR to decapsulate the outer IP header. 

Is my understanding correct? Is there anything I missed? 

Appreciate some experts in the group to help me out. 

Thank you in advance. 

Linda Dunbar

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 10 Oct 2010 09:17:39 -0400 (EDT)

> From: Linda Dunbar <[email-masked]>

    > I get the impression that LISP is ... specifying a mechanism for a
    > gateway router (i.e. ITR) to encapsulate an outer IP header over an IP
    > data frame and ETR to decapsulate the outer IP header.

Well, it's correct so far as it goes, but it's very incomplete: it's rather
like saying that an airplane is a device for burning fuel and creating
thrust. Yeah, that's part of the picture (and a key part), but there's a lot
more to it than that, like wings, etc (and we're also leaving out the _point_
of the whole effort, which is to move stuff around through the air).

The architectural goal of LISP is to start to separate location and identity,
for a whole host of reasons: things like provider independence, multi-homing,
etc, etc. The overall way it does that is to interpose between the
communicating hosts a cloud of boxes (the xTRs) whose job it is to i) augment
the semantics of the packets emitted by hosts (which contain names from only
one namespace, the LEIDS), and augment them with a second (the RLOCs), and
ii) get those packets to the appropriate ETR, which can send it on the actual
destination.

The mechanisms it uses to do all this can be divided into two groups which
match the division above: i) the stuff which, given an LEID, produces the
appropriate RLOC, and ii) the stuff needed to succesfully gets packets from
an ITR to an ETR.

The second part of this is more work than it may look, because what LISP
effectively does is create a new packet-switching layer on top of existing
one, and so ITR-ETR communication runs into a lot of the 'classical' problems
of packet switching: e.g. figuring out if the next-hop box is alive, etc,
etc. And the fact that the fan-out (i.e. number of ITR-ETR links for any
given xTR) is _much_ higher than in any classical packet-switching network
makes this a considerably harder job, since a lot of the mechanisms used to
do this in, e.g. OSPF, don't scale to a fan-out of thousands.

Not that the first is not simple either - the system for finding and
maintaining {LEID -> RLOC} bindings has to be efficient, secure and robust,
and that means dealing with a host of issues, e.g. finding out when a binding
which an ITR has cached has been superseded by a changed version. Etc, etc,
etc...

	Noel