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
