Subject: [lisp] Meeting in Orlando

From: Terry Manderson <[email-masked]>
Date: Thu, 7 Feb 2013 15:50:02 -0800

WG,

The Orlando meeting time is fast approaching.

The draft agenda has us meeting at 0900-1100 (Morning Session I) in
Caribbean 6 on Friday March 15, 2013.

Please keep in mind the following important dates.

* 2013-02-11 (Monday): Working Group Chair approval for initial document
(Version -00) submissions appreciated by UTC 24:00.
* 2013-02-15 (Friday): Final agenda to be published.
* 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00)
submission by UTC 24:00,
* 2013-02-25 (Monday): Internet Draft final submission cut-off by UTC
24:00,
* 2013-02-27 (Wednesday): Draft Working Group agendas due by UTC 24:00,

Please send your requests for agenda items to lisp-chairs@tools,ietf.org
by the 25th February.

Thanks
Terry

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Feb 2013 08:31:53 -0800

Hi,

In RFC6830, Section 5.4.1, it says:

  "the ITR will drop the packet
   when the size is greater than L and send an ICMP Too Big message to
   the source with a value of S, where S is (L - H)."

Shouldn't it be: "when the size is greater than (L - H)" ?

Thanks - Fred
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Feb 2013 09:05:22 -0800

> Shouldn't it be: "when the size is greater than (L - H)" ?

L is the size of the packet that will leave the ITR so it won't be fragmented by the ITR or any intermediate routers. S is the size of the packet that must be received by the ITR to avoid fragmentation.

L-H is S. So if S + H (calculated by the ITR is L) is greater than the effective MTU, that is when the packet is dropped. That is what the text says.

You can explain this in terms of S, of (L-H), or in terms of L. We chose to describe it by how the packet leaves the ITR, in terms of L.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Feb 2013 09:39:26 -0800

Hi Dino,

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2013 9:05 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [lisp] RFC6830 comment
> 
> > Hi,
> >
> L is the size of the packet that will leave the ITR so it won't be
> fragmented by the ITR or any intermediate routers. S is the size of the
> packet that must be received by the ITR to avoid fragmentation.
> 
> L-H is S. So if S + H (calculated by the ITR is L) is greater than the
> effective MTU, that is when the packet is dropped. That is what the text
> says.
> 
> You can explain this in terms of S, of (L-H), or in terms of L. We chose
> to describe it by how the packet leaves the ITR, in terms of L.

OK, I went back and looked again and it looks clear enough.

However, what should the ITR do if it gets an ICMP packet too
big (PTB) message after sending an encapsulated packet to the
ETR. Drop it? Cache the MTU size? Send a translated PTB message
back to the original source? Section 5.4.1 of the document
doesn't currently say.

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Feb 2013 10:56:53 -0800

> back to the original source? Section 5.4.1 of the document

Read the stateful section.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Feb 2013 11:12:27 -0800

> Sent: Tuesday, February 12, 2013 10:57 AM
> To: Templin, Fred L
> Cc: [email-masked]

I did. It's just that the stateless method defaults to stateful if
PTBs arrive. So, purely stateless may not be possible in all cases.
But, it doesn't say that.

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Feb 2013 11:13:44 -0800

> But, it doesn't say that.

Stateful means to store the learned effective MTU with the locator for the map-cache entry

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Feb 2013 11:26:52 -0800

> Stateful means to store the learned effective MTU with the locator for the

Yes, I understand that. My point is that stateless is not possible
if a learned effective MTU has to be stored. The stateless section
should therefore describe the conditions under which it must default
to stateful.

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Feb 2013 13:34:55 -0800

> should therefore describe the conditions under which it must default

Fred, there is stateless and the counter which is stateful. An implementation can do one or the other or both if depending on the cost you want to put towards the solution.

We are not making a recommendation. It is up to the implementor to decide.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Feb 2013 14:07:32 -0800

Hi Dino,

> Fred, there is stateless and the counter which is stateful. An

The ITR is only stateless until which time the network returns
a packet too big - then, it is obliged to either do stateful or
risk black-holing.

> implementation can do one or the other or both if depending on the cost
> you want to put towards the solution.
> 

Not my point, but a fully stateless solution may not always
be possible (my point).

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Feb 2013 14:15:55 -0800

> a packet too big - then, it is obliged to either do stateful or

And who says it is obliged? The specification was written in the way it was for a reason. You want to change it to something else. 

What is your point? And can we get to it with less emails please?

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Feb 2013 14:29:56 -0800

Hi Dino,

> Sent: Tuesday, February 12, 2013 2:16 PM
> To: Templin, Fred L
> Cc: [email-masked]
> And who says it is obliged? The specification was written in the way it
> was for a reason. You want to change it to something else.

It's really very simple; modify the next to last paragraph of
section 5.4.1 such as:

  "When the outer-header encapsulation uses an IPv4 header, an
   implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
   can be avoided.  An implementation MAY either set the DF bit in such
   headers to 0 or adopt the stateful solution in Section 5.4.2 if it has
   good reason to believe there are unresolvable path MTU issues between
   the sending ITR and the receiving ETR."

This also brings home the point that stateless vs stateful can
be on a per-ETR basis rather than all one way or the other.

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Feb 2013 14:58:40 -0800

The whole point of the text, the way it was written is to NOT DO MTU DISCOVERY between the ITR and ETR. That will lead to more packet loss. Avoid it up front by having hosts configure smaller MTUs or do MTUD inside of the site.

The point was to have less mechanism rather than more. We have been telling you this for years Fred. 

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Feb 2013 15:09:04 -0800

Hi Dino,

> Sent: Tuesday, February 12, 2013 2:59 PM
> To: Templin, Fred L
> Cc: [email-masked]
> The whole point of the text, the way it was written is to NOT DO MTU
> DISCOVERY between the ITR and ETR. That will lead to more packet loss.
> Avoid it up front by having hosts configure smaller MTUs or do MTUD inside
> of the site.
> 

Telling me all you want doesn't make the spec bullet-proof
in all deployment scenarios. For example, I just noticed the
deployment scenario document 'draft-ietf-lisp-deployment' where
there seems to be a fair amount of concern for MTU implications
based on placement of the xTRs. But, I haven't followed the LISP
developments closely enough to know how far this document is
along in the process.

Thanks - Fred