Subject: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt

From: [email-masked]
Date: Mon, 13 Apr 2015 04:14:11 -0700

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/

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Apr 2015 16:24:00 +0000

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-masked]

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, April 13, 2015 4:14 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-intarea-gre-ipv6-07.txt
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Apr 2015 17:12:53 +0000

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

> From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, April 14, 2015 9:24 AM
> To: [email-masked]
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt
> 
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Apr 2015 04:29:33 +0000

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

> Sent: Tuesday, April 14, 2015 10:13 AM
> To: [email-masked]