Re: [RRG] Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared

[Robin Whittle <rw@firstpr.com.au>]

Hi Michael,

Thanks for your response.

The first paragraph of mine which you quoted:

>> This means that all three other proposals - LISP-NERD, LISP-CONS
>> and eFIT-APT rely on short caching times to achieve rapid
>> multihoming service restorations.  . . .

was completely mistaken and is not part of my critique:

  http://www.firstpr.com.au/ip/ivip/comp/

Thanks for acknowledging my concerns about incremental adoption and
the difficulty of inspecting packets arriving at an ISP's border
router to filter out ICMP packets.

My use of "CE" as the site of the ITRs was mistaken.  I meant the
ISP's Provider Edge routers, and have updated my critique to reflect
this.

You wrote:

> APT TRs never have to make a decision about which address to tunnel to,
> this decision is made by the default mapper when it provides a mapping
> entry to a TR. 

My comparison reflects this:

   The ITR function of APT TRs does not make any decisions
   regarding which of multiple ETRs to tunnel to in a multihoming
   scenario.

The eFIT-APT ITR does have more complex functionality than Ivip's
ITRs in that it must handle ICMP messages regarding the ETR not
being reachable.  Now, as part of my attempt to cope with PMTUD etc.
Ivip ITRs do have some more complex functions, including receiving
ICMP messages when they send probe packets.  However, this does not
require keeping a cache of information about all recently tunneled
packets.

eFIT-APT and Ivip share some important characteristics.

Firstly, these are the only two ITR-ETR schemes which never delay or
drop a packet.  LISP-NERD and TRRP rely on potentially multiple
global DNS-like lookups, which I think could take seconds.
LISP-CONS relies on a global lookup system, which is supposed to be
faster than DNS, but I think is still bound to be slow enough to
seriously disrupt communications, including (as Brian Carpenter
pointed out) slowing down both directions of a TCP session
establishment handshake.  These delays may also slow down the DNS
requests and responses which precede an attempt to establish a TCP
session.

Secondly, I think eFIT-APT and Ivip are the only two schemes in
which an ITR can be a caching ITR and simply pass on a packet to an
upstream device (default mapper for eFIT-APT or another ITR for
Ivip) which will be able to encapsulate it instantly.  I think that
eFIT-APT's approach to this - using the packet itself as a request
for mapping information to be sent to the ITR - is particular nifty.

However eFIT-APT and Ivip are polar opposites in terms of the speed
of mapping information distribution.


> We have the same goal of simplicity in TRs. I don't see how our TRs are
> more complex than Ivip ITRCs, in fact they do very similar things. We
> only require a mapping *entry* cache (no decisions required, only
> lookups) and, like your Notify messages, our ICMP packets can only serve
> to add or invalidate cache entries.

I think your ITR's task (Default Mappers too) in securely handling
ICMP host-unreachable messages is quite daunting.  The ITR needs to
have a substantial cache of information of recently sent packets -
maybe a few seconds worth.  Then it needs to carefully vet each ICMP
host-unreachable packet it receives against this cache until it
finds an exact match.  I think this is similar to the complexity
required for an ITR to translate ICMP Packet Too Big messages into
ICMP messages to be sent to the sending host, as I wrote about in:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01766.html

 - Robin


--
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