I will say one more thing. When the original source is not within the same administrative domain as the GRE ingress there is no guarantee that PTBs sent by the ingress will make it back to the source. Hence, the ingress should fragment packets up to 1500 bytes (if necessary) and send PTBs for packets larger than 1500 bytes (if necessary).
Then, whether or not the true GRE MTU can be determined depends on where the ingress and egress are located. If both are within the same administrative domain then the ingress can reasonably expect to receive accurate PTBs from either a router on the path or from the egress itself. Otherwise, there is no guarantee that the ingress will receive PTBs. Thanks - Fred [email protected] > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Templin, Fred L > Sent: Tuesday, April 14, 2015 10:13 AM > To: [email protected] > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > I will say also that the act of probing in general is a bit troublesome. In > particular, > when there is Equal Cost MultiPath (ECMP) how can you tell that the probe > packets will follow the same path as the data packets? > > Thanks - Fred > [email protected] > > > -----Original Message----- > > From: Int-area [mailto:[email protected]] On Behalf Of Templin, > > Fred L > > Sent: Tuesday, April 14, 2015 9:24 AM > > To: [email protected] > > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > Hi, in Section 3.2 there is now specification for sending a 1280 byte probe > > packet > > to test the path between the ingress and egress. The stated goal is to > > ensure > > that a 1280 byte packet can traverse the tunnel without fragmentation. > > > > However, if there are other tunnels on the path from the first tunnel > > ingress > > toward the corresponding egress, it is possible that another tunnel could be > > fragmenting and reassembling the probe packet before it arrives at the final > > egress. And, fragmentation and reassembly closer to the middle of the > > network is much worse than fragmentation and reassembly nearer the > > edges of the network. > > > > This is why I have proposed a new "Don't Fragment" bit in the GRE header. > > It can be set by the first tunnel ingress to tell other tunnels not to > > fragment > > the packet that is being used as a probe. Fragmentation and reassembly > > of probe packets must be avoided if we are to avoid fragmentation and > > reassembly of data packets. > > > > Also, it might be worth noting that this is not the first time a tunnel > > loopback > > test packet has been specified. A similar facility is specified in Section > > 8 of > > RFC5969. > > > > Thanks - Fred > > [email protected] > > > > > > > -----Original Message----- > > > From: I-D-Announce [mailto:[email protected]] On Behalf Of > > > [email protected] > > > Sent: Monday, April 13, 2015 4:14 AM > > > To: [email protected] > > > Cc: [email protected] > > > Subject: I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the Internet Area Working Group Working > > > Group of the IETF. > > > > > > Title : IPv6 Support for Generic Routing Encapsulation > > > (GRE) > > > Authors : Carlos Pignataro > > > Ron Bonica > > > Suresh Krishnan > > > Filename : draft-ietf-intarea-gre-ipv6-07.txt > > > Pages : 8 > > > Date : 2015-04-13 > > > > > > Abstract: > > > Generic Routing Encapsulation (GRE) can be used to carry any network- > > > layer payload protocol over any network-layer delivery protocol. GRE > > > procedures are specified for IPv4, used as either the payload or > > > delivery protocol. However, GRE procedures are not specified for > > > IPv6. > > > > > > This document specifies GRE procedures for IPv6, used as either the > > > payload or delivery protocol. It updates the GRE specification, RFC > > > 2784. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/ > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-07 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gre-ipv6-07 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > 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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
