Re: [RRG] LISP-NERD reachability and MTU detection

[Eliot Lear <lear@cisco.com>]

Hi Iljitsch,

First, thanks for your comments regarding NERD both now and in the
IST-RING meeting.  Based on those comments and some from others I intend
to update the NERD draft with a bit more theory of operation, as to what
you do with a NERD once you have it.  This also validates Tony's
comments to me that we shouldn't send an unstable experimental draft to
the RFC Editor ;-)  Second, let me remind people what was said in the
RRG meeting.  The general intent of most folks is to first focus on
LISP-ALT.  I would hence encourage you to devote some thought to ALT,
now that you've done so with NERD ;-)

Now please see below.


Iljitsch van Beijnum wrote:
> After Eliot's presentation today, I started thinking that LISP-NERD
> could benefit greatly from something like the shim6 REAP reachability
> evaluation mechanism. However, with shim6 we have the limitation that
> we have no bits to play with for datapackets belonging to sessions
> that haven't encountered any failures. Not so with NERD: here we have
> additional bits in every packet. I'm assuming that we can use a few of
> those for reachability and MTU detection. It would work like this:

Please note that the LISP architecture at present assumes that we will
survive the tunnel overhead.  We do have the general problem of MTUs
that all tunneling schemes have.  People differ over just how important
this is to solve.  Fred would probably argue "very" while Dino has
argued "not that much".  My own opinion is that over time getting to
1536 isn't that hard.  The bigger problem is getting ABOVE 1536 pre-LISP
(or anything else) encapsulation.   Then you really do need real end to
end MTU discovery, IMHO.

>
> A LISP-NERD ITR chooses an ETR/locator and assumes it's reachable. It
> sets a "please respond" code point in the NERD header and starts a timer. 

s/NERD header/LISP header.  There is only one LISP packet format.  NERD
is merely a way to schmere the data across the globe.

> The ETR receiving the packet sees the "please respond" message and
> sends back info to the originating ITR that could encompass current
> locator preference information (for traffic engineering), the up/down
> status of other ETRs, the maximum packet size the ETR is prepared to
> receive, possibly (if the ETR supports reassembly) the maximum packet
> size the ETR is prepared to reassemble from fragments.

The ETR really only has its interface MTU.  It doesn't look a whole lot
different than any other router.  Again, I think this is a general
tunneling problem, and not something that is specific to LISP.  I do
think the problem is worth considering in LISP's context, but we should
be thinking in more general terms when it comes to solutions (e.g, L2TP,
IPSEC, IP over HTTP, etc., etc.).

Again, thanks for your comments.

Eliot

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