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

From: Ronald Bonica <[email-masked]>
Date: Wed, 29 May 2013 13:36:38 +0000

Folks,

If you get a chance, please provide a sanity check on this document. It is very short, so it won't take much time to review.

                                         Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 29, 2013 9:34 AM
> To: Ronald Bonica
> Subject: New Version Notification for draft-bonica-intarea-gre-mtu-
> 00.txt
> 
> 
> A new version of I-D, draft-bonica-intarea-gre-mtu-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Filename:	 draft-bonica-intarea-gre-mtu
> Revision:	 00
> Title:		 Generic Routing Encapsulation (GRE) Fragmentation
> Strategy
> Creation date:	 2013-05-29
> Group:		 Individual Submission
> Number of pages: 8
> URL:             http://www.ietf.org/internet-drafts/draft-bonica-
> intarea-gre-mtu-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-bonica-intarea-
> gre-mtu
> Htmlized:        http://tools.ietf.org/html/draft-bonica-intarea-gre-
> mtu-00
> 
> 
> Abstract:
>    This memo documents a GRE fragmentation strategy upon which many
>    vendors have converged.  Specifically, it defines procedures to be
>    executed by GRE ingress routers.  It is published so that those
>    building new implementations will be aware of best common practice.
>    It is also published so that those building applications over GRE
>    will understand how GRE works.
> 
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 May 2013 10:28:24 -0700

FWIW, I gave mine to Ron offline already.

Joe

On 5/29/2013 6:36 AM, Ronald Bonica wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 29 May 2013 20:06:27 +0000

Ron, 

I do have a few questions and suggestion about the practices documented in the draft:

- Section 4.1, second paragraph: 
why DF bit "MUST" set to 1  when the payload header has "0"? I would think default should be same as the "payload" DF setting. 

- Section 5.1, last sentence: "The GRE egree router will forward the payload fragments to their ultimate destination where there will be reassembled"

The GRE egress router should reassemble the fragmented payloads before sending to the destination.  In general, the network outside the Egress router should be same as the network before entering the Ingress router. If the data frame size is less than then MTU of the network before entering the Ingress router, the decapsulated frame size should be less than the MTU of the network outside the Egress router. 

In addition, it is the Ingress node split the frame, the final destination may not be aware of how to reassemble the data frame. 

- There should be two options when the encapsulated data frame exceeds MTU: a) split the data frame to two smaller frames, with each frame being encapsulated; b) truncate the frame if the Egress node needs to receive the data frame but doesn't have the capability to reassemble split frames. 

Linda

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ronald Bonica
> Sent: Wednesday, May 29, 2013 8:37 AM
> To: Internet Area
> Subject: [Int-area] FW: New Version Notification for draft-bonica-
> intarea-gre-mtu-00.txt
> 
> Folks,
> 
> If you get a chance, please provide a sanity check on this document. It
> is very short, so it won't take much time to review.
> 
>                                          Ron
> 
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 May 2013 13:31:45 -0700

> why DF bit "MUST" set to 1  when the payload header has "0"? I would think default should be same as the "payload" DF setting.

DF in a tunnel header should be set to match the capability of that 
tunnel mechanism. Either the tunnel wants to find the MTU and match it 
or not; in the former case, it has to set DF=1 all the time.

For this doc, whether to set or copy the DF bit depends on whether PMTUD 
is supported on a given tunnel. If it is (whether PMTUD or PLMTUD), then 
set DF; otherwise, I agree - copy DF.

> - Section 5.1, last sentence: "The GRE egree router will forward the
> payload fragments to their ultimate destination where there will be
> reassembled"
>
> The GRE egress router should reassemble the fragmented payloads
> before sending to the destination. In general, the network outside
> the Egress router should be same as the network before entering the
> Ingress router. If the data frame size is less than then MTU of the
> network before entering the Ingress router, the decapsulated frame
> size should be less than the MTU of the network outside the Egress
> router.

I agree; my general recommendation has always been "the egress should 
always clean up any mess created by an ingress" - which means using 
"outer" fragmentation rather than "inner".

Yes, this can cause repeated frag/reassembly, but the alternative is to 
shift work to the end host, which I think is inappropriate. Further, 
this sort of clean-up is required by IPv6 and for IPv4 when when DF=1 on 
the inner packet anyway.

> In addition, it is the Ingress node split the frame, the final
> destination may not be aware of how to reassemble the data frame.

This is a spurious point; the information is there if the inner packet 
was fragmentable.

> - There should be two options when the encapsulated data frame
> exceeds MTU: a) split the data frame to two smaller frames, with each
> frame being encapsulated; b) truncate the frame if the Egress node
> needs to receive the data frame but doesn't have the capability to
> reassemble split frames.

There are two viable options:

	- fragment and reassemble (same as your option "a)" above)

	- drop the packet (and presumably send a signal upstream)

Sending a truncated frame serves no useful purpose.

Joe

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 30 May 2013 06:58:22 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Joe Touch
> 发送时间: 2013年5月30日 4:32
> 收件人: Linda Dunbar
> 抄送: Ronald Bonica; Internet Area
> 主题: Re: [Int-area] FW: New Version Notification for
> draft-bonica-intarea-gre-mtu-00.txt
> 
> 
> 
> > why DF bit "MUST" set to 1  when the payload header has "0"? I would think
> default should be same as the "payload" DF setting.
> 

Post-fragmentation could degrade the performance on the egress tunnel point due to some reason, e.g., packet disorder. Therefore, prefragmentation should always be preferred since it can shift the reassembly work from the egress tunnel point to the end hosts.

> this sort of clean-up is required by IPv6 and for IPv4 when when DF=1 on

In the above case, the packet should be dropped by the ingress tunnel point.

Best regards,
Xiaohu

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 30 May 2013 14:54:04 +0000

Hi Linda,

Thanks for reading the document. Comments inline......

> From: Linda Dunbar [mailto:[email-masked]]
> Sent: Wednesday, May 29, 2013 4:06 PM
> To: Ronald Bonica; Internet Area
> Subject: RE: [Int-area] FW: New Version Notification for draft-bonica-
> intarea-gre-mtu-00.txt
> 
> Ron,
> 
> why DF bit "MUST" set to 1  when the payload header has "0"? I would
> think default should be same as the "payload" DF setting.

The actual text of the document is:

"When the GRE ingress router tunnels an IPv4 payload over IPv4, and the DF Bit in the payload header is set to 0 (May Fragment), **by default**, the GRE ingress router MUST set the DF bit in the delivery header to 1.  However, implementations MAY include a configuration option that allows the DF bit to be copied from the payload header to the delivery header."

We say this because we want to avoid reassembly in the GRE egress router, and in order to avoid that, we need to avoid fragmentation by tunnel interior routers.

However, this is only a default behavior. If an operator doesn't mind reassembly on the GRE egress router, there may be a configuration knob that allows the DF-bit to be copied from the payload header to the delivery header. However, operators should use that knob only if that is really what they want to do.

> The GRE egress router should reassemble the fragmented payloads before
> sending to the destination.  In general, the network outside the Egress
> router should be same as the network before entering the Ingress
> router. If the data frame size is less than then MTU of the network
> before entering the Ingress router, the decapsulated frame size should
> be less than the MTU of the network outside the Egress router.
> 

Just to be sure that we aren't talking past each other, let's ensure that we are talking about the same scenario. The GRE egress router receives
complete, non-fragmented packets, containing fragmented payloads. So, if the deliver header is IPv4, its fragment offset is equal to 0 and its MF-bit is also set to 0. If the delivery header is IPv6, it does not contain a fragment header. However, the payload is a single fragment of a larger packet.

Are we talking about the same scenario?

If so, it would be undesirable for the egress router to attempt reassembly for the following reasons:

- There are conditions in which the payload destination will be able to reassemble the packet, but the GRE ingress router cannot. For example, assume that the packet was fragmented several hops before entering the GRE tunnel. One fragment traversed the GRE tunnel, but another fragment traversed another path, avoiding the tunnel. In this case, the tunnel egress router can't reassemble the packet, because all of the fragments will not pass through it. However, the destination host can reassemble the packet.

- Even if the GRE egress router could reassemble he packet, it is preferable to execute the computationally expensive reassembly procedure at the endpoint.

> - There should be two options when the encapsulated data frame exceeds
> MTU: a) split the data frame to two smaller frames, with each frame
> being encapsulated;

This is the option that the draft currently offers. (Or am I misunderstanding your words?)

 b) truncate the frame if the Egress node needs to
> receive the data frame but doesn't have the capability to reassemble
> split frames.

I don't understand this option. Are you suggesting that we deliver the beginning of the payload packet and discard the rest? I doubt if that is what you mean, but that is how I currently interpret your words.

                                           Ron

> > If you get a chance, please provide a sanity check on this document.
> > It is very short, so it won't take much time to review.
> >
> >                                          Ron
> >
> >

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 30 May 2013 22:38:23 +0000

Ron, 

Comments are inserted below:

> Just to be sure that we aren't talking past each other, let's ensure
> that we are talking about the same scenario. The GRE egress router
> receives
> complete, non-fragmented packets, containing fragmented payloads. 

[Linda] The scenario I am talking about is: 
   The packet arriving at the Ingress node is has packet size less than the MTU. When the ingress node adds the GRE header, the new packet size exceeds the MTU. When this happens, the Ingress node has to break the received the packet to two (half) frames, encapsulate each half frame with proper GRE header, and send two separate encapsulated frames to Egress node. 

Is this same as your scenario?  From your description below, it doesn't sound like the same. 
If it not the same, this scenario should be included in the draft. I can provide a section to describe this scenario and proper processing in Ingress node and Egress node. 

Under my scenario, the Egress node needs to reassemble the two half frames before sending to the destination because each half frame is not a complete IP packet. 

>
>So,
> if the deliver header is IPv4, its fragment offset is equal to 0 and
> its MF-bit is also set to 0. If the delivery header is IPv6, it does
> not contain a fragment header. However, the payload is a single
> fragment of a larger packet.
> 
> - There are conditions in which the payload destination will be able to
> reassemble the packet, but the GRE ingress router cannot. For example,
> assume that the packet was fragmented several hops before entering the
> GRE tunnel. One fragment traversed the GRE tunnel, but another fragment
> traversed another path, avoiding the tunnel. In this case, the tunnel
> egress router can't reassemble the packet, because all of the fragments
> will not pass through it. However, the destination host can reassemble
> the packet.
> 
> - Even if the GRE egress router could reassemble he packet, it is
> preferable to execute the computationally expensive reassembly
> procedure at the endpoint.
> 
> exceeds
> I don't understand this option. Are you suggesting that we deliver the
> beginning of the payload packet and discard the rest? I doubt if that
> is what you mean, but that is how I currently interpret your words.
> 
>                                            Ron
> 
> >
> > Linda
> >
> >
> >
> >
> > > >    vendors have converged.  Specifically, it defines procedures
> to
> > be

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 31 May 2013 13:05:36 +0000

> > receives complete, non-fragmented packets, containing fragmented
> > payloads.
> 
>    The packet arriving at the Ingress node is has packet size less than
> the MTU. When the ingress node adds the GRE header, the new packet size
> exceeds the MTU. When this happens, the Ingress node has to break the
> received the packet to two (half) frames, encapsulate each half frame
> with proper GRE header, and send two separate encapsulated frames to
> Egress node.
> 
> 
> If it not the same, this scenario should be included in the draft. I
> can provide a section to describe this scenario and proper processing
> in Ingress node and Egress node.
> 
> Under my scenario, the Egress node needs to reassemble the two half
> frames before sending to the destination because each half frame is not
> a complete IP packet.
> 
> 

Hi Linda,

The scenarios are nearly the same. In the scenario that I describe, packet (size > TMTU). In the scenario that you describe (MTU > packet size > TMTU). The difference between the two scenarios isn't significant. You should get the same behavior either way.

Given this scenario, the GRE ingress has the following choices:

1) fragment the payload and forward each payload fragment through the tunnel. The egress receives N complete, non-fragmented packets. Each of those packets contains a fragment of the payload. The egress forwards the fragments to the payload destination for reassembly.
2) do not fragment the payload. Alternatively, forward it through the tunnel, causing the delivery (outer) packet to be fragmented.  The tunnel egress router reassembles the fragments of the delivery packet and forwards the payload to its destination.

Today, most implementations do #1, because reassembly is computationally expensive and they want to push computationally expensive activities out to the endpoint.

One might argue that there are advantages to pros and cons of each strategy. While I am not averse to documenting those, the purpose of this document existing practice. It is not to change how people implement GRE.

                                                                        Ron