Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:[email protected]] > Sent: Thursday, April 09, 2015 11:13 AM > To: Templin, Fred L; [email protected] > Subject: RE: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu > > Fred, > > What happens when a legacy device that supports 2784 and 2890 receives a > packet that is fragmented
That would only happen when an augmented ingress send a fragmented packet to a legacy egress that it knows nothing about - an unmanaged situation. Two solutions are 1) allow the ingress to use the augmented behavior when it knows that the egress also supports the behavior, or 2) send the egress a little test packet for which the egress can only respond if is supports the augmentation. > as per draft-ietf-intarea-gre-mtu? I think you meant per draft-templin-intarea-grefrag? > Is that behavior acceptable? The ingress should only use the augmented behavior when it knows that the egress also supports the behavior - e.g., via administrative configuration, test packet probing. etc. Thanks - Fred [email protected] > > Ron > > > > -----Original Message----- > > From: Templin, Fred L [mailto:[email protected]] > > Sent: Thursday, April 09, 2015 1:44 PM > > To: Ronald Bonica; [email protected] > > Subject: RE: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu > > > > Hi Ron, > > > > > -----Original Message----- > > > From: Int-area [mailto:[email protected]] On Behalf Of Ronald > > > Bonica > > > Sent: Thursday, April 09, 2015 10:37 AM > > > To: [email protected] > > > Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu > > > > > > Fred, > > > > > > How would you achieve backwards compatibility with legacy > > > implementations? If backwards compatibility cannot be achieved, maybe > > you are talking about a new protocol, that will ultimately replace GRE? > > > > Haven't thought about it too much, but I assume backwards compat would > > be handled in the same way that it was handled when RFC2784 was updated > > by RFC2890. That is why this document says "updates RFC2784 and RFC2890". > > > > Plus, two new bits have been carved out of the Reserved0 field in the GRE > > header and, if the bits are non-zero, it is a pretty good indication that > > the > > fragment header is included. > > > > Thanks - Fred > > [email protected] > > > > > Ron > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > > > > > > > Title : GRE Tunnel Fragmentation > > > > Author : Fred L. Templin > > > > Filename : draft-templin-intarea-grefrag-00.txt > > > > Pages : 5 > > > > Date : 2015-04-09 > > > > > > > > Abstract: > > > > GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet > > > > when the delivery packet exceeds the tunnel MTU, or when otherwise > > > > necessary. This can cause problems when unmitigated IPv4 > > > > fragemntation ensues, or when middleboxes drop IPv6 fragments > > > > unconditionally. This document proposes GRE tunnel fragmentation > > > > which avoids these pitfalls.. > > > > > > > > > > > > > > _______________________________________________ > > > 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
