Subject: Opsdir last call review of draft-ietf-6man-mtu-option-12

From: Sheng Jiang via Datatracker <[email-masked]>
Date: Tue, 08 Feb 2022 22:29:24 -0800

Reviewer: Sheng Jiang
Review result: Ready

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.

Document: draft-ietf-6man-mtu-option-12
Reviewer: Sheng Jiang
Review Date: 2022-02-09

This experimental document specifies a new mechanims to in-boundly discover the
minimum Path MTU along the forward path between a source host to a destination
host with a newly defined IPv6 Hop-by-Hop option that is used to record .  The
document is well-writen and reader-friendly. It clearly defines the behaviours
on each devices with different roles. This document also have a special section
9 to explain the "experiment goals" of this specification.

However, personally, I still not fully understand why this document are
intending for "experimental" and what would be the experiment range. It seems
for me this mechanism are good enough to be a proposed standard to persuade
people use it widely. If by deploying it, issues are found or refining are
needed. We can always update it as normal IETF procedure.

Summary: Ready

Major Concerns:

None.

Minor Concerns:

None.

Regards,

Sheng

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 9 Feb 2022 10:22:40 +0000

Sheng Jiang via Datatracker wrote on 09/02/2022 06:29:
> people use it widely.

The draft proposes to add bottom-of-the-stack functionality to a 25yo 
protocol, via a mechanism which is known to cause substantial packet 
loss on production networks (see rfc7872).

The reliability of the proposed mechanism was brought up several times 
during discussion at WG level, e.g.

https://mailarchive.ietf.org/arch/msg/ipv6/QrfdW0omcigRdPy2VECa_82oAEY/

The difficulty with MTU negotiation is that getting the MTU wrong will 
cause packet blackholing.

In other words, the draft specifies a protocol enhancement whose stated 
aims imply increased reliability, which depends on a mechanism which is 
known to be highly unreliable in practice, and where misconfiguration 
can cause serious reliability issues.

This is not P-S territory.

Separate to this, there is no running code that I'm aware of.  There are 
certainly no implementation reports.

There is no discussion in the draft of HBH reliability. It would be 
appropriate if the ID quoted some of the EH reliability reports due to 
operational concerns.

Nick

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 9 Feb 2022 12:02:14 +0000

Thanks Nick,

see below some observations.

> loss on production networks (see rfc7872).
Yes, loss of packets that carry the HBH PMTU was discussed. In 
particular, loss of DPLPMTUD probes.

> https://mailarchive.ietf.org/arch/msg/ipv6/QrfdW0omcigRdPy2VECa_82oAEY/
RFC8899, notes how that packet loss can impact classical PMTUD, but also 
suggests how to handle this when using DPLPMTUD.

> cause packet blackholing.
Much less so using DPLPMTUD?
> In other words, the draft specifies a protocol enhancement whose 
> stated aims imply increased reliability, which depends on a mechanism 
> which is known to be highly unreliable in practice, and where 
> misconfiguration can cause serious reliability issues.
>

Wait, that's a pretty large brush being used here.

DPLPMTUD advocates the use of sacrificial probe packets, where failure 
to deliver does not black-hole traffic If a sender sets a HBH option on 
some of its probe packets, then those probe packets can be lost because 
they carry this option - this would waste some network capacity with no 
benefit. I'm not sure I'd see this as less reliable.

What misconfiguration could lead to "serious reliability issues"?

>
> Separate to this, there is no running code that I'm aware of. There 
> are certainly no implementation reports.
>

Gorry

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Feb 2022 15:24:23 +0000

> It seems

You have it a bit backwards. We don't write standards to persuade people to use them.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 11 Feb 2022 13:05:26 +0000

Gorry,

> particular, loss of DPLPMTUD probes.

It was discussed, and the draft includes some text which alludes to 
this.  One thing that's missing is an acknowledgement of the scale of 
packet loss associated with HBH options which is detailed in RFC7872.

> Wait, that's a pretty large brush being used here.

Yes, it is, just as the blast radius for potential problems caused by 
changes to the bottom of a protocol stack is pretty wide.

Nick