Ron,
Comments are inserted below:
-Original Message-
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.
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
Linda
-Original Message-
From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org]
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
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
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
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
