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: [email protected] [mailto:[email protected]] > 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: [email protected] [mailto:[email protected]] > > > > 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
