Subject: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

From: Ronald Bonica <[email-masked]>
Date: Fri, 14 Feb 2014 20:26:09 +0000

Folks,

Please review and comment

                Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 3:06 PM
To: Ronald Bonica; Dr. Joseph D. Touch; Joe Touch; Carlos Pignataro; Ronald Bonica; Carlos Pignataro
Subject: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

A new version of I-D, draft-bonica-intarea-gre-mtu-04.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-bonica-intarea-gre-mtu
Revision:	04
Title:		A Fragmentation Strategy for Generic Routing Encapsulation (GRE)
Document date:	2014-02-12
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-bonica-intarea-gre-mtu-04.txt
Status:         https://datatracker.ietf.org/doc/draft-bonica-intarea-gre-mtu/
Htmlized:       http://tools.ietf.org/html/draft-bonica-intarea-gre-mtu-04
Diff:           http://www.ietf.org/rfcdiff?url2=draft-bonica-intarea-gre-mtu-04

Abstract:
   This memo specifies a default GRE tunnel fragmentation strategy,
   which has been implemented by many vendors and widely deployed on the
   Internet.

   This memo also specifies requirements for GRE implementations.
   Having satisfied these requirements, a GRE implementation will
   execute the default GRE tunnel fragmentation strategy, specified
   herein, with minimal configuration.  However, with additional
   configuration, the GRE implementation can execute any of the tunnel
   fragmentation strategies defined in RFC 4459.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Feb 2014 21:19:37 +0000

Hi Ron,

In Section 4.1, when the GRE ingress emits packets that *might* undergo
IPv4 fragmentation on the path to the egress, the ingress needs to use
rate limiting to ensure that no IPv4 reassembly misassociations occur a
the egress [RFC6864][RFC4963]. If the ingress has some way of discovering
that no IPv4 fragmentation will occur, it can then suspend rate limiting
and send at full line rates [draft-templin-aerolink].

Thanks - Fred
[email-masked]

> From: Int-area [mailto:[email-masked]] On Behalf Of Ronald Bonica
> Sent: Friday, February 14, 2014 12:26 PM
> To: [email-masked]
> Subject: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt
> 
> Folks,
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized
> version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Fri, 14 Feb 2014 13:31:05 -0800

Hi, Fred,

Yes, this doc should definitely include a discussion of 6864. We'll tend 
to that in the next revision.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Feb 2014 18:51:40 +0000

Hi Ron,

The document needs to talk about packet sizes for IP payload packets.
For IP payload packets no larger than MINMTU bytes, the GRE tunnel
MUST accommodate the packet even if a small amount of fragmentation
is necessary. (Here, the mandatory MINMTU for IPv6 is 1280 and the
recommended MINMTU for IPv4 is also 1280.)

Beyond MINMTU, there needs to be a balance between avoiding path
MTU related black holes for the source and avoiding excessive
fragmentation at the GRE tunnel egress. This balance is situation
dependent. For example, if the GRE tunnel ingress is located close
to the source, it should be reasonable to expect that the source
would be able to receive any ICMP PTB messages sent by the ingress.
Or, if the GRE tunnel egress is located close to the destination,
it should be reasonable to expect that the egress can perform a
small amount of reassembly.

If the GRE tunnel ingress is located "far" from the source, then it
must strive to ensure that packets up to 1500 bytes are accommodated
even if a small amount of fragmentation is necessary, since 1500 is
the MTU size configured by the vast majority of host links in the
Internet. For packets larger than 1500 bytes, the GRE tunnel ingress
should not allow fragmentation, as this would cause excessive
reassembly for the tunnel egress.

So, a suitable algorithm for the GRE tunnel ingress would be:

1) For IP payload packets no larger than MINMTU, encapsulate in the
   GRE delivery headers (with DF=0 in the outer IP header for IPv4).
   If the packet is larger than GMTU, fragment the delivery packet
   and send all fragments to the tunnel egress (or, for IPv4, allow
   the network to do the fragmentation). (If the delivery packet
   did not require fragmentation, then just send unfragmented.) 

2) For IP payload packets larger than MINMTU but no larger than 1500,
   if the packet is larger than GMTU and the ingress is located near
   the source, drop the packet and return an ICMP PTB. Otherwise,
   encapsulate in the GRE delivery headers (DF=0). If the payload
   packet is larger than GMTU, fragment the delivery packet and
   send all fragments to the tunnel egress (or, for IPv4, allow
   the network to do the fragmentation). (If the delivery packet
   did not require fragmentation, then just send unfragmented.)

3) For IP payload packets larger than 1500, if the packet is larger
   than GMTU drop and return an ICMP PTB. If the packet is no larger
   than GMTU, encapsulate and send unfragmented with DF=1.

In this algorithm, if IPv4 is used as the delivery protocol and there
is reason to believe that some fragmentation may occur on the path,
the GRE tunnel ingress MUST institute rate limiting per RFC6864 to
ensure that no reassembly misassociations occur. The ingress can test
to see if fragmentation is needed by sending an occasional encapsulated
1500 byte "ping" packet to the egress for which no fragmentation is
permitted. If the ping succeeds, the ingress can suspend fragmentation
and/or rate limiting. (This would constitute RFC4821 for tunnels.)

As an added means for minimizing fragmentation, the GRE tunnel ingress
can use MSS clamping to rewrite the TCP MSS size in the IP payload
packet to a smaller size [RFC0879][RFC6691]. This option may not be
available to all GRE tunnel ingresses however (e.g., if there are
multiple nested levels of encapsulation).

An underlying assumption in all of this is that sources that send
IP packets larger than 1500 are expected to use RFC4821 to ensure
that the larger packets are not being dropped into a black hole.
This should become a BCP recommendation for the Internet even
without respect to tunneling.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 08:47:12 -0800

Hi, Fred,

> The document needs to talk about packet sizes for IP payload packets.

Yes, and I'm hoping we can add additional detail.

Here's my view:

-- path MTU is based on the min of the largest packet each link in the path can support

-- links often transit packets larger than their native size, e.g., ATM's MTU is 9K, not 48 bytes

-- links do have a native transit size, though

So there ought to be two very different concepts

- MTU (maximum)

- PTU (preferred)

IMO, much of the confusion about how MTUs are handled by tunnels is based on confusing MTU to mean PTU.

I.e.,

	- a tunnel has a PTU based on avoiding ingress fragmentation
	and egress reassemly

	- a tunnel as a MTU, which is the MTU of the path of the tunnel
	minus the headers it adds at the ingress

> recommended MINMTU for IPv4 is also 1280.)

This artificially limits tunnel MTU based on trying to support a perceived PTU, but doesn't match PTU.

> fragmentation at the GRE tunnel egress.

If we really want to accomplish that, we need to flesh out the difference between MTU and PTU and teach our apps to focus on PTU, ala a new PLPTUD (vs. current PLMTUD).

I don't think we should be guessing this at the time we specify the tunnel, because the approach varies based on what's transited (real IP packets or some other sort of encapsulation, e.g., IPsec in UDP).

> This balance is situation

Tunnels transit packets; they're not connected to sources or destinations. So are you proposing that a tunnel should now try to discover the length of the path in each direction and handle different addresses differently? IMO, that's worse than reassembly.

> small amount of reassembly.

Same problem, and worse- do you expect vendors to sell different tunnel engines based on intended traffic patterns?

----

In conclusion, I would urge this document to focus on MTU as the goal, at which point the only packets that ought to be dropped at the ingress ought to be those that cannot be encapsulated with another IPv4 header, i.e., that exceed the *MAXIMUM* payload size.

If we want to tune for preferred path size, we need to extend PLMTUD for that purpose.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Feb 2014 17:27:05 +0000

Hi Joe,

You seem to be talking past me - maybe it was because I wrote too much.
The fragmentation story for tunnels is very simple as follows:

1) IPv6 has a minimum MTU of 1280 bytes. So, packets that are no larger
   than this size MUST be accommodated even if a small amount of
   fragmentation is necessary. IPv4 has a much smaller minMTU, but
   IMHO tunnels SHOULD behave as if the IPv4 minMTU is also 1280.

2) Packets larger than 1500 bytes (with the exception of IPv4 packets
   with DF=0) should be allowed to sink or swim on their own. Tunnels
   therefore MUST NOT use fragmentation for packets larger than 1500.

3) Packets larger than 1280 but no larger than 1500 are in a "gray area"
   where the way the tunnel accommodates them depends on the specific
   tunnel orientation. In some cases the tunnel should send as a whole
   packet. In others, it should drop and send a PTB. In still others,
   it should fragment. The cases are easy to articulate.

That is really all there is to it. What is important to realize is
that case 3) needs to be architected according to the specific tunnel
orientation - there is no generic one-size-fits-all rule that can be
applied to all tunnels in all orientations.

Thanks - Fred

> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, February 18, 2014 8:47 AM
> To: Templin, Fred L
> Cc: Ronald Bonica; [email-masked]
> Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt
> 
> Hi, Fred,
> 
> If we really want to accomplish that, we need to flesh out the difference between MTU and PTU and
> teach our apps to focus on PTU, ala a new PLPTUD (vs. current PLMTUD).
> 
> I don't think we should be guessing this at the time we specify the tunnel, because the approach
> varies based on what's transited (real IP packets or some other sort of encapsulation, e.g., IPsec in
> UDP).
> 
> 
> Tunnels transit packets; they're not connected to sources or destinations. So are you proposing that a
> tunnel should now try to discover the length of the path in each direction and handle different
> addresses differently? IMO, that's worse than reassembly.
> 
> In conclusion, I would urge this document to focus on MTU as the goal, at which point the only packets
> that ought to be dropped at the ingress ought to be those that cannot be encapsulated with another
> IPv4 header, i.e., that exceed the *MAXIMUM* payload size.
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 10:08:45 -0800

> The fragmentation story for tunnels is very simple as follows:

Yes, IMO they are, and here's mine:

	- if a tunnel CAN transit a packet, it MUST try

		i.e., the MTU of a tunnel that uses IPv6 encapsulation
		is 65535 - encapsulation headers

	- if a tunnel CANNOT transit a packet, it rejects it

		i.e., anything larger than "65535 - encap headers"

Everything else mistakes MSS (maximum) for PSS (preferred). Preferred is 
the min of the MSS's. An IPv6 tunnel limits MSS only insofar as packets 
larger than 65535-headers cannot traverse it.

So...

>     IMHO tunnels SHOULD behave as if the IPv4 minMTU is also 1280.

An IPv6 tunnel is a link to the IPv6 protocol. IPv6 requires that the 
smallest MTU of all links must be no less than 1280. So agreed.

>     therefore MUST NOT use fragmentation for packets larger than 1500.

Completely disagree. The max size of the payload of GRE in IPv6 is much 
larger than 1500.

You're trying to do something at the tunnel layer that the path is 
supposed to be in control of.

>     it should fragment. The cases are easy to articulate.

There is no grey area. Until the max payload of an IPv6 packet is 
decreased, there's simply no justification to do other than the above.

> applied to all tunnels in all orientations.

First, if rules depend on orientations, then there would be no rule for 
tunnels at all. You cannot specify the requirements of a tunnel if it 
depends on network placement - that rule does not exist for any other 
Internet component (excepting only endpoint vs. network, but that's 
function, not just placement).

Second, there is a rule. See above.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Feb 2014 18:22:30 +0000

Hi Joe,

I can see that I am going to have to write a draft on generic tunnel
fragmentation. It will be based on my e-mail from two messages ago.
I have already written drafts on 6rd tunnel fragmentation and AERO
tunnel fragmentation, and they are already consistent with the to-
be-written draft on generic tunnel fragmentation. Your draft on GRE
fragmentation can then also cite the generic tunnel fragmentation doc.

Thanks - Fred

> Sent: Tuesday, February 18, 2014 10:09 AM
> To: Templin, Fred L

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 10:28:32 -0800

On 2/18/2014 10:22 AM, Templin, Fred L wrote:
> fragmentation.

That's already a section in the tunnel draft that has been a WG doc:

http://tools.ietf.org/html/draft-ietf-intarea-tunnels-00#section-3.2

That doc has languished for lack of feedback, but IMO that's the place 
to put all one-stop information on tunnels that transit IP packets.

I do agree that the current GRE doc could be more clear on this issue, 
but I don't think a new, separate doc on this is needed.

Joe

> It will be based on my e-mail from two messages ago.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Feb 2014 18:44:36 +0000

Hi Joe,

> Sent: Tuesday, February 18, 2014 10:29 AM
> To: Templin, Fred L

I can articulate one-stop generic text for tunnel fragmentation. Are
you suggesting reviving the above document?
 
> but I don't think a new, separate doc on this is needed.

Each tunnel type can certainly articulate its own fragmentation
scheme if it wants to - I have already done that for 6rd and AERO:

https://datatracker.ietf.org/doc/draft-foo-v6ops-6rdmtu/
https://datatracker.ietf.org/doc/draft-templin-aerolink/

But, would be better if the individual docs could point to a
one-stop generic text and then just give 1-2 sentences on their
specific adaptation of the generic text. Would that work for you?

Thanks - Fred
 
> >>>> IMO, much of the confusion about how MTUs are handled by tunnels is based on confusing MTU to
> mean
> >>>> PTU.
> >>>>
> >>>> I.e.,
> >>>>
> >>>> varies based on what's transited (real IP packets or some other sort of encapsulation, e.g.,
> IPsec
> >> in
> >>>> UDP).
> >>>>
> >>>>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 18 Feb 2014 18:45:00 +0000

Folks,

I think that we are conflating two separate efforts.

Draft-bonica-intarea-gre-mtu describes what is widely deployed today. In today's, one of the following conditions frequently holds:

- the operator of the GRE ingress knows that the GRE egress cannot reassemble fragments at the required rate
- the operator of the GRE ingress has no information regarding whether the GRE egress can reassemble fragments at the required rate

Therefore, in draft-bonica, by default, the PTU is equal to the MTU. Fragmentation doesn't happen in the tunnel. However, in the exceptional case, where the operator of the ingress knows that the egress can reassemble at the required rate, fragmentation of the delivery packet is permitted.

The draft that Joe and Fred are considering applies to environments where egress routers are commonly capable of reassembling at line rate. Since this is a different environment, it should be addressed in a separate draft.

                                               Ron

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, February 18, 2014 1:29 PM
To: Templin, Fred L
Cc: Ronald Bonica; [email-masked]
Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

> I can see that I am going to have to write a draft on generic tunnel 

-

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Feb 2014 18:51:12 +0000

Hi Ron,

What you are describing is easily articulated in the generic text
that would apply to all tunnel types - not just GRE. The draft Joe
and I are considering would be a generic document and not anything
that assumes any specific reassembly capabilities, for example.

Thanks - Fred

> From: Ronald Bonica [mailto:[email-masked]]
> Sent: Tuesday, February 18, 2014 10:45 AM
> To: Joe Touch; Templin, Fred L
> Cc: [email-masked]
> Subject: RE: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt
> 
> Folks,
> 
> Therefore, in draft-bonica, by default, the PTU is equal to the MTU. Fragmentation doesn't happen in
> the tunnel. However, in the exceptional case, where the operator of the ingress knows that the egress
> can reassemble at the required rate, fragmentation of the delivery packet is permitted.
> 
> The draft that Joe and Fred are considering applies to environments where egress routers are commonly
> capable of reassembling at line rate. Since this is a different environment, it should be addressed in
> a separate draft.
> 
>                                                Ron
> 
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 10:52:51 -0800

> you suggesting reviving the above document?

Yes; it already is supposed to be one-stop, generic text for all tunnel 
issues, and has a section on MTU issues already. Can you let us know 
what part of that needs to be fixed?

> https://datatracker.ietf.org/doc/draft-templin-aerolink/

The generic description should explain how and why the rules should 
vary. In that case, then specifics do belong in specific tunnel specs.

> specific adaptation of the generic text. Would that work for you?

Yes, but again that's already the purpose of the Intarea tunnel doc, 
which already has a lot of different discussions like this (ICMP signal 
relaying, MTU, etc.).

Joe

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 18 Feb 2014 18:58:13 +0000

Hi Fred,

All the more reason to address the issue in a separate draft!

                         Ron

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Tuesday, February 18, 2014 1:51 PM
To: Ronald Bonica; Joe Touch
Cc: [email-masked]
Subject: RE: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

Hi Ron,

What you are describing is easily articulated in the generic text that would apply to all tunnel types - not just GRE. The draft Joe and I are considering would be a generic document and not anything that assumes any specific reassembly capabilities, for example.

Thanks - Fred

> Draft-bonica-intarea-gre-mtu describes what is widely deployed today. 
> In today's, one of the following conditions frequently holds:
> 
> - the operator of the GRE ingress knows that the GRE egress cannot 
> reassemble fragments at the required rate
> - the operator of the GRE ingress has no information regarding whether 
> the GRE egress can reassemble fragments at the required rate
> 
> Therefore, in draft-bonica, by default, the PTU is equal to the MTU. 
> Fragmentation doesn't happen in the tunnel. However, in the 
> exceptional case, where the operator of the ingress knows that the egress can reassemble at the required rate, fragmentation of the delivery packet is permitted.
> 
> The draft that Joe and Fred are considering applies to environments 
> where egress routers are commonly capable of reassembling at line 
> rate. Since this is a different environment, it should be addressed in a separate draft.
> 
>                                                Ron
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Feb 2014 19:02:21 +0000

Hi Joe,

> Sent: Tuesday, February 18, 2014 10:53 AM
> To: Templin, Fred L

Sure, I will take a crack at this.

> vary. In that case, then specifics do belong in specific tunnel specs.

Yes, there will still be a place for specific tunnel specs, but
with heavy emphasis on the generic. The key is in the placement
of the tunnel egress and ingress in determining the specific
adaptations of the generic text to apply.

> which already has a lot of different discussions like this (ICMP signal

Do we have agreement that the Intarea tunnel doc would be
revived then (looks like it has been expired for a while now).

Thanks - Fred

> >>>>>> This artificially limits tunnel MTU based on trying to support a perceived PTU, but doesn't
> match
> >>>> PTU.
> >>>>>>
> >>>>>> Same problem, and worse- do you expect vendors to sell different tunnel engines based on
> intended
> >>>>>> traffic patterns?
> >>>>>>
> >>>>>> ----
> >>>>>>

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 11:02:19 -0800

> Draft-bonica-intarea-gre-mtu describes what is widely deployed

Understood, but it also out to explain how that corresponds to what 
should be done, referring to a generic doc to explain the details of 
what should be done.

> - the operator of the GRE ingress has no information regarding
> whether the GRE egress can reassemble fragments at the required rate
>
> Fragmentation doesn't happen in the tunnel. However, in the exceptional
> case, where the operator of the ingress knows that the egress can
> reassemble at the required rate, fragmentation of the delivery packet is
> permitted.

Understood, but as Fred points out, that means that the GRE tunnel is 
non-compliant with IPv6 requirements. That needs to be discussed, even 
if we admit that this is current operation.

> The draft that Joe and Fred are considering

It's a draft that I and Mark Townsley already wrote. We started in 09 at 
the request of a few different ADs, as an effort to aggregate 
recommendations about how to tunnel IP packets, but it got virtually no 
discussion on the list.

FWIW, it's still in the INTAREA charter, and still a WG doc, even 
thought he current draft expired.

 > applies to environments
> where egress routers are commonly capable of reassembling at line rate.

All tunnels that cannot transit an IPv6 minimum MTU unfragmented MUST 
ingress fragment and egress reassemble. Otherwise you're noncompliant 
with IPv6, i.e., you're not a valid IPv6 link.

Any tunnel that uses IPv6 internally MUST therefore fragment/reassemble. 
Whether they can at line rate or not determines whether they're broken 
or not, not whether the spec has changed.

> Since this is a different environment, it should be addressed in a
> separate draft.

Neither of us is debating whether this should be a separate draft; every 
tunnel mechanism needs a distinct presentation. The issue is how much 
this doc should explain the issues and/or try to rationalize a 
noncompliant solution simply because it's deployed.

IMO, we ought to explain what it DOES, discuss whether it's compliant, 
and include what it would need to become compliant if not.

And refer to the tunnel draft for the details. That draft ought to be 
revived (I can easily resubmit) and we ought to wrap-up the 
recommendations in that doc and get it out the door (finally).

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 11:14:49 -0800

On 2/18/2014 11:02 AM, Templin, Fred L wrote:
...
> revived then (looks like it has been expired for a while now).

IMO, yes. I think there has been a need for this doc for a while, but 
maybe the last few years the community has caught up and finally there's 
a clear need rather than seeing this as merely proactive.

Joe

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 19 Feb 2014 02:53:46 +0000

Joe,

> 		is 65535 - encapsulation headers

Where is this specified (other than stated by you in your email with 2119 language)? This defeats the purpose of a configurable MTU, and frankly shows requirements that do not exist and are not met in real life.

Take for example RFC 1812, Section 3.3.4., "MTU":

   The MTU of each logical interface MUST be configurable within the
   range of legal MTUs for the interface.

   Many Link Layer protocols define a maximum frame size that may be
   sent.  In such cases, a router MUST NOT allow an MTU to be set which
   would allow sending of frames larger than those allowed by the Link
   Layer protocol.  However, a router SHOULD be willing to receive a
   packet as large as the maximum frame size even if that is larger than
   the MTU.

   DISCUSSION
...

Apologies as I have said the following on this list more than once, but to reiterate: if you consider a tunnel as a logical link, the "link max frame size" is 64k - tunnel encap. But that does *not* mean that's the MTU, nor that packets larger than the tunnel MTU need to be fragmented after encap because they fit this max link size.

If the MTU is configured on an ethernet link to be 500 B, but the physical media can (capable) send larger sizes, what happens with a 1000B packet?

> Everything else mistakes MSS (maximum) for PSS (preferred). Preferred is the min of the MSS's. An IPv6 tunnel limits MSS only insofar as packets larger than 65535-headers cannot traverse it.
> 

Similarly, where is "preferred" specified? And these are segment sizes and not MTUs?

Thanks,

-- Carlos.

> An IPv6 tunnel is a link to the IPv6 protocol. IPv6 requires that the smallest MTU of all links must be no less than 1280. So agreed.
> 
> Completely disagree. The max size of the payload of GRE in IPv6 is much larger than 1500.
> 
> You're trying to do something at the tunnel layer that the path is supposed to be in control of.
> 
> There is no grey area. Until the max payload of an IPv6 packet is decreased, there's simply no justification to do other than the above.
> 
> First, if rules depend on orientations, then there would be no rule for tunnels at all. You cannot specify the requirements of a tunnel if it depends on network placement - that rule does not exist for any other Internet component (excepting only endpoint vs. network, but that's function, not just placement).
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 19 Feb 2014 02:54:33 +0000

+1.

Thanks,

-- Carlos.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Feb 2014 16:05:57 +0000

Hi Ron,

> capable of reassembling at line rate. Since this is a different environment, it should be addressed in

No, that is not correct - the draft we are considering accounts for all
environments in which tunnel ingresses and egresses may be deployed.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Feb 2014 08:15:09 -0800

Carlos,

On 2/18/2014 6:53 PM, Carlos Pignataro (cpignata) wrote:
> Where is this specified (other than stated by you in your email with
> 2119 language)?

Nowhere, and it need not be specified. It's basically the definition of 
an MTU.

> This defeats the purpose of a configurable MTU, and
> frankly shows requirements that do not exist and are not met in real life.
>

RFC1812 is a spec for routers (gateways), not for tunnels. A tunnel is a 
link, where two or more links interconnect at a gateway.

I.e., the *link* has an MTU, which is defined as the largest message 
that can traverse the link. It's not defined as the largest message that 
can traverse the link without fragmentation inside the link.

The context of the above requirement is the configurable value within 
the router. Sure, the router operator can override the link MTU by 
setting an *interface* MTU <= link MTU.

However, when we specify a tunnel technology, we are talking about the 
link MTU, not the interface MTU.

>     packet as large as the maximum frame size even if that is larger than

The above basically says, in other words, "routers MUST NOT set the 
interface MTU larger than the link MTU, and routers SHOULD receive 
packets larger than the interface MTU as long as it is no larger than 
the link MTU".

Again, for tunnels, we're talking about the link MTU.

> Apologies as I have said the following on this list more than once,
> but to reiterate: if you consider a tunnel as a logical link, the "link
> max frame size" is 64k - tunnel encap. But that does *not* mean that's
> the MTU, nor that packets larger than the tunnel MTU need to be

the interface MTU...

> fragmented after encap because they fit this max link size.

max link size = tunnel MTU.

It does mean that the egress MUST be capable of reassembling any packet 
no larger than the tunnel MTU.

So the *tunnel MTU* is 64K.

Yes, at the router, the *interface MTU* may override this to a lower 
value as a configuration parameter.

> If the MTU is configured on an ethernet link to be 500 B, but the

you configure an interface MTU, not a link MTU

> physical media can (capable) send larger sizes, what happens with a
> 1000B packet?

at the router, that depends on the interface MTU - if it's 500B, then 
the packet would be dropped by the router and an ICMP PTB sent upstream.

note that this router MUST be able to reassemble (at the "link layer", 
i.e., the added IP header) fragments that transit a 1000B IP packet, 
even if the interface MTU is 500B.

>> Everything else mistakes MSS (maximum) for PSS (preferred).
>> Preferredis the min of the MSS's. An IPv6 tunnel limits MSS only insofar as
>> packets larger than 65535-headers cannot traverse it.
>>
>
> Similarly, where is "preferred" specified?

I was introducing that term.

> And these are segment sizes and not MTUs?

Nope; I mistyped, and meant MTU and PTU, but I think the concept is 
equally applicable to transport layer segments (MSS and PSS).

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Feb 2014 08:18:45 -0800

> environments in which tunnel ingresses and egresses may be deployed.

+1 and -1

+1 that the Intarea tunnel doc should address the generic case of 
tunnels that transit IP packets, including as many specific examples as 
possible.

-1 that the GRE tunnel spec needs to start with "what is deployed", but 
should compare that to the Intarea tunnel doc and provide a set of 
"SHOULD" recommendations to help transition GRE tunneling to follow BCP.

(IMO the Intarea doc is really targeted as a BCP, even though previously 
issued as informational).

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Feb 2014 16:27:20 +0000

Hi Joe,

> Sent: Wednesday, February 19, 2014 8:19 AM
> To: Templin, Fred L; Ronald Bonica
> Cc: [email-masked]

I am OK with that. The same is true of my drafts on 6rd MTU and
AERO MTU. They will wrap themselves around the generic intarea
tunnel doc and then tell the restricting conditions that are
specific to those environments.

> issued as informational).

That sounds right to me.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Feb 2014 18:14:11 +0000

Hi Joe,

> So the *tunnel MTU* is 64K.

For IPv6-over-IPv6 tunnels, the MTU is actually 4G. Do we
want to mention jumbograms somewhere?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Feb 2014 10:25:59 -0800

Yup.

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 19 Feb 2014 18:34:37 +0000

Fred,

Can you provide a normative citation for the requirement that you state, below?

                 Ron

>For IPv6-over-IPv6 tunnels, the MTU is actually 4G. Do we want to mention jumbograms somewhere?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Feb 2014 18:48:06 +0000

Hi Ron,

> Can you provide a normative citation for the requirement that you state, below?

Sure - RFC2675.

Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 19 Feb 2014 19:38:57 +0000

Fred,

The word "tunnel" does not appear in RFC 2675.

                               Ron

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, February 19, 2014 1:48 PM
To: Ronald Bonica; Joe Touch; Carlos Pignataro (cpignata)
Cc: [email-masked]
Subject: RE: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

Hi Ron,

Sure - RFC2675.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Feb 2014 20:17:37 +0000

Hi Ron,

> Sent: Wednesday, February 19, 2014 11:39 AM
> To: Templin, Fred L; Joe Touch; Carlos Pignataro (cpignata)
> Cc: [email-masked]

That's OK; it doesn't need to. But the generic tunnel doc will
say that the more specific tunnel specs are free to define a
jumbo-in-jumbo encapsulation format since the length of an
IPv6 packet is not restricted to 64KB.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Feb 2014 23:38:55 -0800

FWIW, this refers to the existing draft in the intarea about tunnels, 
which is being 'revived'. I just confirmed with Mark Townsley, and he 
and I are revising that one shortly.

Joe