Subject: <draft-ietf-6man-rfc1981bis-00.txt>

From: Bob Hinden <[email-masked]>
Date: Thu, 3 Mar 2016 10:32:10 -0800

Hi,

I published a the first w.g. draft version of <draft-ietf-6man-rfc1981bis-00.txt>.   Links below.

The version has the changes that were discussed at the Yokohama 6MAN session.  The changes include:

    - Added text to discard an ICMP Packet Too Big message
      containing an MTU less than the IPv6 minimum link MTU.

    - Revision of text regarding RFC4821.

    - Added R. Hinden as Editor to facilitate ID submission.

    - Editorial changes.

A diff from the previous version can be found at:

http://tools.ietf.org//rfcdiff?url1=draft-hinden-6man-rfc1981bis-01&url2=draft-ietf-6man-rfc1981bis-00

This is part of the project to move the core IPv6 specifications to Internet Standard.

Thanks,
Bob

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Maintenance of the IETF.
> 
>        Title           : Path MTU Discovery for IP version 6
>        Authors         : Jack McCann
>                          Stephen E. Deering
>                          Jeffrey Mogul
>                          Robert M. Hinden
> 	Filename        : draft-ietf-6man-rfc1981bis-00.txt
> 	Pages           : 16
> 	Date            : 2016-03-03
> 
> Abstract:
>   This document describes Path MTU Discovery for IP version 6.  It is
>   largely derived from RFC 1191, which describes Path MTU Discovery for
>   IP version 4.  It obsoletes RFC1981.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-00

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 3 Mar 2016 18:50:50 +0000

Hi Bob,

Please change:

   "It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD) designed for
    use in environments in which  delivery of ICMP messages to a host are not assured."

to:

   "It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD) designed for
    use over paths for which  delivery of ICMP messages to a host are not assured."

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Thursday, March 03, 2016 10:32 AM
> To: IPv6 List
> Cc: Bob Hinden
> Subject: <draft-ietf-6man-rfc1981bis-00.txt>
> 
> Hi,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 10 Mar 2016 16:43:08 +0000

Hi Bob,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Thursday, March 03, 2016 10:51 AM
> To: Bob Hinden; IPv6 List
> Subject: RE: <draft-ietf-6man-rfc1981bis-00.txt>
> 
> Hi Bob,
> 
> Please change:
> 

This is an important point that needs to be addressed since use or non-use of
PLPMTUD  is a per-path consideration. Consider for example that a host within
a well-managed administrative domain can use classical PMTUD alone for paths
that terminate within the same administrative domain, but it may need to employ
PLPMTUD for paths that terminate within different administrative domains.
Please confirm that this point will be addressed.

Thanks - Fred

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Thu, 10 Mar 2016 17:00:08 +0000

Fred,

> On Mar 10, 2016, at 4:43 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Bob,
> 

I would like to see what others in the w.g. think about your proposed text.

Bob

---

From: 神明達哉 <[email-masked]>
Date: Thu, 10 Mar 2016 10:58:00 -0800

At Thu, 10 Mar 2016 17:00:08 +0000,

> I would like to see what others in the w.g. think about your proposed text.

Frankly, I don't see a substantial difference between these two
versions; it just seems to be a subtle wording tweak.  So I personally
have no problem with the new proposed text (or for that matter, I'm
equally fine with the original one).

(I guess others raised the same question) I would wonder how the host
determines whether the delivery of ICMP is assured or not, whether
it's in an "environment" (current version) or over a "path" (proposed
one), but the same question applies to both versions, so that doesn't
affect whether to adopt the proposed text given that we already
adopted the current one.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 10 Mar 2016 19:11:13 +0000

Hi,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Thursday, March 10, 2016 10:58 AM
> To: Bob Hinden
> Cc: Templin, Fred L; IPv6 List
> Subject: Re: <draft-ietf-6man-rfc1981bis-00.txt>
> 

I think the distinction is important. RFCs 1981(bis) and 4821 are about *path*
MTU determination; not environment MTU determination. The mechanisms
are applied on a per-path basis, and the ICMP delivery attributes of some
paths may be quite different than those of others.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2016 08:19:03 +1300

> I would like to see what others in the w.g. think about your proposed text.

Hosts are generally unaware of paths; all they know about is interfaces, addresses
and first-hop routers. Paths can change unpredictably during the life of a flow.
Any presumption that hosts can make path-dependent decisions to try PLPMTUD seems
wrong to me. They will try PLPMTUD on each flow, as described in RFC4821, or not
at all. So in the context of *this* document, an imprecise word like "environment"
seems appropriate. Any further discussion would belong in a RFC4821bis.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 10 Mar 2016 19:39:27 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, March 10, 2016 11:19 AM
> To: Bob Hinden; Templin, Fred L
> Cc: IPv6 List
> and first-hop routers.

The simplest representation of a path is the destination address, or possibly
the destination address plus flow label, and the host already has to keep
track of these in the destination cache. So, if the host knows that certain
destinations (e.g., those that are in the subnet as itself) are not susceptible
to ICMP loss it should be able to apply PMTUD alone without having to
apply PLPMTUD.

> Paths can change unpredictably during the life of a flow.

I think there is a discussion that needs to happen regarding RFC4821 in terms
of how path MTU information is shared. For example, if there is ECMP in the
path then the RFC4821 probes of a first application might take very different
paths than the probes of a second application, i.e., even if both applications
used the same flow label. This implies that RFC4821 path MTU information
cannot be safely shared between different applications. Meanwhile, the
situation for classical PMTUD is quite different. If there is ECMP in the path,
then classical PMTUD will eventually converge to the minimum MTU for all
paths in the multipath and so the path MTU information can be cached in the
network layer and shared by all applications.

That is one of the reasons why it is better to use classical PMTUD instead of
PLPMTUD whenever possible, which is to say over paths for which classical
PMTUD is not susceptible to ICMP loss. With classical PMTUD, every packet
is a probe with a negative acknowledgment in the form of an ICMP message
if there is a restricting link in the path.

Thanks - Fred

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 11 Mar 2016 10:37:06 +0100

神明達哉 wrote:
> Bob Hinden<[email-masked]>  wrote:
>
>>>> Please change:
>>>>
IMHO "paths" is more correct, so I think Fred's proposed text is better.

It might be possible for implementers to determine "path" via some other 
means e.g. reading routing tables of intermediate routers, or signaling 
received from a locally terminated tunnel endpoint, although I readily 
admit this is far fetched for the generic case of the global Internet.

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 11 Mar 2016 09:44:45 +0000

Brian,

> On Mar 10, 2016, at 7:19 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I think this is largely correct, we don’t have any real concept of a path, flow is a little closer, but as you say a host only knows the exit interface, next hop router, and destination address.  How the packet get there is opaque.

On the other hand PMTUD and PLPMTUD both use the word “path” quite a lot.  This terminology dates back to RFC1191.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Mar 2016 08:05:32 +1300

> On the other hand PMTUD and PLPMTUD both use the word “path” quite a lot.  This terminology dates back to RFC1191.

Yes. I've been having an off-list discussion with Fred T about this, and I think
that the difficulty lies in RFC4821, or as you say back in RFC1191. The problem
is that the PMTU may change unpredictably if the actual path changes, but
the sending host cannot know this. RFC4821 is fairly explicit that it works
on the assumption that the path doesn't change most of the time. I think it's
sloppy that all of these documents don't state more clearly that the destination
address is a only a weak proxy for the path (especially if there is ECMP
or load balancing somewhere). But I don't think that 1981bis is the place
to fix this.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Mar 2016 20:45:41 +0000

Hi Brian,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, March 11, 2016 11:06 AM
> To: Bob Hinden
> Cc: IPv6 List
> > I think this is largely correct, we don’t have any real concept of a path, flow is a little closer, but as you say a host only knows the exit
> interface, next hop router, and destination address.  How the packet get there is opaque.
> >

Then, to really make things right we would have to go back and change
all documents to say "Destination MTU Discovery"?

For better or worse, the term "Path MTU Discovery" is deeply embedded
in the Internet nomenclature - irreversibly so, as far as I can tell. It got
started circa 1987 around the same time that "Fragmentation Considered
Harmful" was published and continued through the publication of the
RFCs in question.

We all know that the destination in the destination cache is the node's
local representation of a "path", and we also know that paths can
fluctuate dynamically resulting in increases or decreases in the path
MTU at a given point in time. But, it is still called "Path MTU Discovery";
not "Destination MTU Discovery" nor "Environment MTU Discovery".
So, that would seem to indicate a need for consistency.

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Mon, 14 Mar 2016 14:00:01 -0700

Fred,

> On Mar 11, 2016, at 12:45 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Brian,
> 

Given the use of “path” in these document, I don’t object to changing “environment” to “path”.   I agree with Brian that rfc1981bis is not the place to try to clarify the meaning and scope of “path”, but I don’t see any harm using “path” in this summary of PLPMTUD

I will plan to make this change in the next update unless someone objects.

Bob