Subject: Re: TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04

From: Bob Hinden <[email-masked]>
Date: Fri, 17 Mar 2017 14:57:23 -0700

Joe,

Thanks for the detailed review.

Several of the reviews have suggested significant changes to this document.  The working group was trying to make a few changes to bring it into alignment with some changes to rfc2460bis (based on updating documents).  It was not attempting a major rewrite when advancing it to Internet Standard.  The alternative that the working group discussed was to file errata on RFC1981 and leave it to a future document update.

I don’t think many of these changes can be done and still advance it to Internet Standard. If we can’t advance the current document, then the w.g. may want to just do the errata and withdraw the advancement request.  Of course, if people want to work on a revision of IPv6 Path MTU Discovery, it would be welcomed, but it won’t be able to advanced to Internet Standard.

Comments below.

Thanks,
Bob

> On Feb 15, 2017, at 1:51 PM, Joe Touch <[email-masked]> wrote:
> 
> Document: draft-ietf-6man-rfc1981bis-04
> Reviewer: Joe Touch
> Review Date: February 15, 2017
> IETF LC End Date: March 3, 2017
> IESG Telechat date: February 28, 2017
> 
> Review result: significant issues
> 
> NOTE: some of this review is informed by tracking some of the issues raised by others on the IETF list, notably Gorry Fairhurst.

In my response to Gorry, I proposed some changes to the document.

> 
> Major issues:
> 
> 1) the current text is insufficiently realistic about the (in)ability of this mechanism to operate in current networks, regardless of the support for generating ICMPs at routers or PMTUD support at endpoints, due to ICMP filtering for security reasons. [this comment is already being addressed by consensus text]

As far as I can tell, we don’t have much much information on how much ICMPv6 PTB messages is filter or not.  It’s clearly a problem with IPv4 ICMP PTB, but I haven’t see any recent data regarding ICMPv6 PTB messages.  IPv6 deployment has increased significantly since the last data I saw and it may or may not be a significant problem.

> 
> 2) the current text is insufficiently clear on on the difference between the path MTU, which determines the largest supported IPv6 fragment, vs. the effective MTU to receive (EMTU_R), which determines the largest IP packet that can transit between the source and destination. The document should be more explicit throughput about its goal being to manage or avoid IPv6 source fragmentation rather than about source to destination packet maximums, and in specific in clearly referring to maximum fragments or atomic packets rather than maximum packets.
> 
> E.g.: see the following text, which is incorrect in its current form:
>    Nodes not implementing Path MTU Discovery use the IPv6 minimum link
>    MTU defined in [
> I-D.ietf-6man-rfc2460bis
> ] as the maximum packet size.
> 
> The value used by either Path MTU Discovery or its default represents the path MTU, which is the largest IPv6 *fragment* (or atomic packet, see RFC6864) that can be supported on the path between the endpoints. The maximum IP packet size is limited by the effective MTU to receive (EMTU_R) [RFC1122], which is at least 1500 bytes for IPv6 and not necessarily related to the link MTUs. The text should also clearly indicate that there is no ICMP mechanism for determining larger EMTU_R support.
> 
> E.g., the following text is also incorrect in its current form:
>    The value sent in the TCP MSS option is independent of the PMTU.
>    This MSS option value is used by the other end of the connection,
>    which may be using an unrelated PMTU value.
> 
> The first sentence is correct because TCP MSS is related to EMTU_R (and needs to account for headers, as per RFC6691), and EMTU_R is not directly related to the PMTU (except that it would never be smaller than the PMTU). The MSS option is calculated from EMTU_R, not PMTU.
> 
> In addition, it should be noted that ICMPv6 PTB messages are NOT sent when source fragmentation is enabled.

I think these are all good issues to cover in a rewrite, but I don’t see how they can be done now.

> 
> 3. need verification of current support for some features, esp. regarding TCP and NFS interactions
> See Gorry's note of 2/14/17

Please see my responses to his review.

> 
> 4. the concept of a single path MTU value between two IP addresses does not account for multipath routing, e.g., ECMP (as currently deployed, noted in RFC7690, which should be cited) or BANANA (and its solutions in development) See Fred Templin's posts on this on 2/15/17
> 
> Minor issues:
> 
> - some of the updates and/or current text could be updated to reflect current terminology or practice. See Gorry Fairhursts's post of 2/14/17

I suggest some changes to address some of the issues he raised.

> 
> - fragmentation, while considered harmful and costly, is absolutely necessary to support tunnels even in the presence of PMTUD. The text on this issue should reflect this reality.
> 
> - the requirement that transports be notified of PTB messages might usefully cite the corresponding IPv4, TCP, and UDP sections of RFC1122

I think that is doable.  Please suggest some specific text.

> - section 5.4 should cite and include context from RFC6691, especially including a discussion of the impact of variable IP EHs on the interaction between TCP MSS and ICMP PTB
> 

Please suggest some specific text.

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Mar 2017 15:54:46 -0700

Hi, Bob (et al.),

Although I appreciate the goal of avoiding a major rewrite, I cannot see
how to advance this document with these substantive errors intact.
Moving forward in its current state propagates these errors.

Note that there are also two points below that you did not address:

- item #4 about ECMP

- the minor issue bullet point about the need for fragmentation

I'll hold off suggesting text as requested below until you decide how to
proceed.

Joe

---

From: Bob Hinden <[email-masked]>
Date: Fri, 17 Mar 2017 16:31:32 -0700

Joe,

I think this will be up to the AD and IESG.

If you (and others) want to work on a major update, I am happy to share the XML.  I hope we don’t end up with can’t move the current document forward, and no one wants to do a major update.

Thanks,
Bob

> On Mar 17, 2017, at 3:54 PM, Joe Touch <[email-masked]> wrote:
> 
> Hi, Bob (et al.),
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Mar 2017 17:36:14 -0700

> I think this will be up to the AD and IESG.
OK - I'll wait for them to respond.
> If you (and others) want to work on a major update, I am happy to share the XML.  I hope we don’t end up with can’t move the current document forward, and no one wants to do a major update.
I'd certainly prefer to have this doc address these issues.

One question - if a major update occurred, would that be at the same
standard level? If so, and if these issues are of concern, I'd be glad
to take that on.

If a major rev is a standards-level setback, that would be less useful.

I'd like to hear their views...

Joe

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 18 Mar 2017 11:03:17 -0500

I may not be answering the question Joe asked, but ...

On Mar 17, 2017 19:36, "Joe Touch" <[email-masked]> wrote:

> If you (and others) want to work on a major update, I am happy to share
the XML.  I hope we don’t end up with can’t move the current document
forward, and no one wants to do a major update.
I'd certainly prefer to have this doc address these issues.

So, RFC 1981 is a Draft Standard, which is theoretically a bigger deal than
a Proposed Standard. If a replacement to RFC 1981 doesn't work the same way
that RFC 1981 works, I don't see how it would also be a Draft Standard,
based on the standards level of the RFC it would be replacing. Do others
see something I'm missing?

However.

Assuming that a replacement for RFC 1981 Path MTU Discovery doesn't have
the issues we've been talking about in these threads, I would hope that we
could publish that replacement at Proposed Standard (not at Experimental).

Given that we don't use the Draft Standard level for advancing standards
track RFCs any more (post https://datatracker.ietf.org/doc/rfc6410/), would
publishing a replacement that works better than RFC 1981 at Proposed
Standard be a bad thing?

Curiously yours,

Spencer

Joe

_______________________________________________
Tsv-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Joe Touch <[email-masked]>
Date: Sat, 18 Mar 2017 09:26:43 -0700

FWIW, I was thinking of an update that focused on the description issue
below.

Nothing functionally would change.

Joe

On 3/18/2017 9:03 AM, Spencer Dawkins at IETF wrote:
> On Mar 17, 2017 19:36, "Joe Touch" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     > If you (and others) want to work on a major update, I am happy
>     to share the XML.  I hope we don’t end up with can’t move the
>     current document forward, and no one wants to do a major update.
> So, RFC 1981 is a Draft Standard, which is theoretically a bigger deal
> than a Proposed Standard. If a replacement to RFC 1981 doesn't work
> the same way that RFC 1981 works, I don't see how it would also be a
> Draft Standard, based on the standards level of the RFC it would be
> replacing. Do others see something I'm missing?
>
> However.
>
> Assuming that a replacement for RFC 1981 Path MTU Discovery doesn't
> have the issues we've been talking about in these threads, I would
> hope that we could publish that replacement at Proposed Standard (not
> at Experimental).
>
> Given that we don't use the Draft Standard level for advancing
> standards track RFCs any more (post
> https://datatracker.ietf.org/doc/rfc6410/), would publishing a
> replacement that works better than RFC 1981 at Proposed Standard be a
> bad thing?
>
> Curiously yours,
>
> Spencer
>
>
>     Joe
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tsv-art>
>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 18 Mar 2017 11:29:32 -0500

Hi, Joe,

On Mar 18, 2017 11:27, "Joe Touch" <[email-masked]> wrote:

Ah - I'm glad I asked!

Thanks,

Spencer

Joe

However.

Curiously yours,

Spencer

Joe