Subject: [lisp] [#4] Re: LISP errors

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2009 05:44:04 -0400

>>>>> "Templin," == Templin, Fred L <[email-masked]> writes:

    Templin,> In addition to errors that may occur along the path from
    Templin,> the ITE to the ETE *before* decapsulation and errors
    Templin,> that may occur along the path from the ETE to the final
    Templin,> destination *after* decapsulation, errors may also occur
    Templin,> *during* decapsulation. An example is what if the ETR
    Templin,> decapsulates the outer IP header, but the inner IP stack
    Templin,> is not configured? (Answer is that the ITR should
    Templin,> receive an error by which it can ascertain that this ETR
    Templin,> is having trouble, and should start using a different
    Templin,> ETR instead.)

    Templin,> This gives rise to a type of error message that is
    Templin,> neither fish nor fowl, i.e., it is neither an RLOC-based
    Templin,> nor an EID-based ICMP error - it is a *LISP* error
    Templin,> instead. One approach is to have the ETR send such a
    Templin,> LISP error back to the ITR with enough identifying
    Templin,> credentials such that the ITR can be reasonably sure the
    Templin,> message is authentic.  The message should further not be
    Templin,> dropped by packet filters on the path from the ETR to
    Templin,> the ITR that filter "naked" ICMP messages.

Fred, this is opened as issue #4.
I've attached the following chair note to the issue:

Fred opened this issue before the issue tracker was available.
Discussion on the list suggested that Fred's original conception might
not have WG consensus, but the general problem of when LISP should
send errors and how this should be done definitely is an open issue.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Aug 2009 09:11:33 -0700

Sam,

I was going to post this on a new subject heading, but
your message has given me an appropriate platform since
it calls for a new LISP error for handling MTU as follows:

1) Let the ITR encapsulate all IPv6 packets and all IPv4
packets with DF=1 in the UDP/LISP headers and an outer IPv4
header with DF=0. The ITR then sends the encapsulated packet
into the tunnel as long as it is smaller than the cached MTU
value (see step 3).

2) If the ETR receives the first-fragment of a fragmented
IPv4/UDP/LISP packet, it sends a LISP "Too Big" error message
back to the ITR that tells the ITR it is sending packets that
are too large. The ETR otherwise discards all IPv4 fragments,
i.e., it does not perform IPv4 reassembly (gasp!).

3) Upon receiving a LISP "Too Big" message from an ETR, the
ITR caches the size reported in the message and uses it to
determine when to admit future packets into the tunnel vs
when to drop them and return an ICMP PTB (see step 1).

So, this is both a revision to the MTU handling discipline
as well as a call for a new LISP error message type (the
LISP "Too Big" message).

Comments?

Fred
[email-masked] 

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, August 12, 2009 2:44 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: [#4] Re: [lisp] LISP errors
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2009 12:23:51 -0400

>>>>> "Templin," == Templin, Fred L <[email-masked]> writes:

    Templin,> Sam, I was going to post this on a new subject heading,
    Templin,> but your message has given me an appropriate platform
    Templin,> since it calls for a new LISP error for handling MTU as
    Templin,> follows:

Fred, this is definitely off topic for this thread and is very close
to reopening an issue that the working group has closed.  I strongly
suggest that you find someone to bring any MTU issues that you may
still have to the WG in their own words with particular emphasis on
what the problem is rather than the solution.

Sam Hartman
LISP co-chair