Hi Linda, Thanks for reading the document. Comments inline......
> -----Original Message----- > From: Linda Dunbar [mailto:[email protected]] > 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, > > 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. 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. > > - 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. > 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 > > 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
