Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-datagram-plpmtud-17

Warren Kumari <> Tue, 31 March 2020 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 873703A2378 for <>; Tue, 31 Mar 2020 09:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KfV54y_YVxMG for <>; Tue, 31 Mar 2020 09:02:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CEBE73A237B for <>; Tue, 31 Mar 2020 09:02:18 -0700 (PDT)
Received: by with SMTP id w1so22526641ljh.5 for <>; Tue, 31 Mar 2020 09:02:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=prmX2htDAeyK78vc5aWFSli6+1MF/j1OwCr4vXQhZbg=; b=D3JsuKDKQbK2Pt3ow2ti1zqYxiTP7RnANrEPy3a2kuIKEKLHXvWbZosey1nvzgbbUB UyMSeFQhC1AqnIUWx2xHt7mPcMUhITGmWh2NxYyjYzD+YXJoFIB0FeRpn3VIoCf98ONp a0PPzx6QzYbkplX+RNznLC9ANcrC+y73hxSGcP0kWksfncXvSBijwkLKbo43AfX+6hEm ps5zJhwP3DW5RwhuVWbOVqsiBtMDy4j7cBSYNWPl76Ez6PVfjkLHdruGZHdFkrMm3bmG gdyOYKmCwyXmX9cZwn4YLo7qAfXQCPnO/8zzKWGHCgjQKhBkJL11cl4xwOEzAK7ruonY EMvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=prmX2htDAeyK78vc5aWFSli6+1MF/j1OwCr4vXQhZbg=; b=QceXMpcWgIYvOdkTVekTHuHwA+Yvh5lHdenA0AO9s3vjVcMtIbyukjIhA1pAxfFyHc TG1diTE/sG0O4FTWFEWWUaDgi0vR0IAkwP0rd30dQLgSo/H72HjPZZqCmIQn9XXrvToO qrxoS3qdxRoLKWduWD88nxnktMXUJHepG9pwLpXwiaFQ571kpTaM3hoT/Waq0o/ra64l ov5O3gdFrwOOUy21xBiytbUxy8n7GWPYp8PstEQUImx/zfe5f5yw3DJWcZmTOOBTdfgg ViB+MM49CA2l7RqvN5QJj1CfEYwqdI3TtNxyADTNm4HqvJoNZzbNG5i9XthNNO6AAjTb 1ZgQ==
X-Gm-Message-State: AGi0PuZY0J+cEHNaTsL1DwkuYr2PEBQCWstQh9Up7Bcmx95P56J0a9nm CF2vlkv72tt1qGD8VhsrlycIDviKTkkILqwgJK7fkQ==
X-Google-Smtp-Source: APiQypKUw1jN12HVq2kiQfokCmVmAm8yQOkdHYq0iNGgkGEMsdPYL/rFfWCBgn1HmiO0JJmppBLBkZh0loRJ+H5BA8s=
X-Received: by 2002:a2e:8e2a:: with SMTP id r10mr10502398ljk.276.1585670536566; Tue, 31 Mar 2020 09:02:16 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Tue, 31 Mar 2020 12:01:40 -0400
Message-ID: <>
To: Tim Chown <>
Cc: ops-dir <>,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-datagram-plpmtud-17
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Mar 2020 16:02:22 -0000

[ - last-call@ for clutter ]

Thank you Tim for such a clear and thorough review; these are really helpful.

Authors / WG - please review and address these; I rely on the
directorate to help me evaluate documents...


On Tue, Mar 31, 2020 at 10:20 AM Tim Chown via Datatracker
<> wrote:
> Reviewer: Tim Chown
> Review result: Has Nits
> Hi,
> 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.
> This document defines Datagram Packetization Layer Path MTU Discovery
> (DPLPMTUD) as a new, robust mechanism for applications or transport protocols
> to handle path MTU discovery, rather than relying on the somewhat problematic
> classic PMTUD.
> Overall, the document is well written with a good structure.  In my view it is
> Ready for publication, subject to some nits being considered and addressed.  I
> had held off on this review at Gorry's request until -17 was out.  My comments
> follow below; these are all generally nit-level.
> General comments:
> None.
> There are some ordering issues, esp. around Sec 4.6.2 where terms defined later
> in the doc are used before they are defined.  But that should be easy to fix.
> I did notice a few extra commas in the text; I’ve not called these out, and
> assume the RFC editor will pick these up, probably better than me!
> Specific comments:
> Sec 1.1
> Is there anything to be added here regarding problematic PTB delivery wrt
> protocols that insert headers into packets, rathe than encapsulating them, such
> as the case of one variant of IPv6 segment routing?
> Sec 1.2
> Para 3 - if there is no response to the probe, might the PLPMTU remain the same
> rather than being reduced?  Just steady state operation?  There is a separate
> case of a larger probe failing, as against the path MTU changing (becoming
> smaller) over time?  (This is implicitly mentioned in case 2 of section 4.3)
> Sec 2
> The first mention here of DPLPMTUD doesn’t actually say what the acronym is.
> It’s only expanded later in the document.
> Definition of Link - is that “layer and tunnels” or :”layer tunnels” ?
> Sec 4.1
> First mention of AEAD not expanded.
> Last para - maybe add “Maximum Segment Lifetime” to the definitions in section
> 2?
> Sec 4.3
> I think it would be clearer if
> “There are three ways to detect black holes:”
> read
> “There are three such indicators that allow detection of black holes:”
> The three methods may have different responsiveness to a change in underlying
> MTU; should that be mentioned and briefly discussed?   There’s a brief mention
> of this issue in the last para of 4.6.1.
> Perhaps this section could have - “Reducing PLPMTU” appended to the subject.
> Section 4.6.1
> First line, maybe “utilization and validation of”
> Penultimate para, maybe say “as discussed in the Security Considerations”
> section or similar.
> Section 4.6.2
> Many of the terms here are only defined later in Sec 5.1.2, e.g., BASE_PLPMTU.
> So you need to either add a foreword pointer, or change the order of things
> around.  Took me a little while to find that the terms were not yet mentioned.
> Sec 5
> Second para - is there any way to detect if both layers are running DPLPMTUD?
> Also, here you say “SHOULD NOT”, later the doc says it’s “desired” that this
> doesn’t happen.
> Section 5.1.2
> Last term, BASE_PLPMTU - why is 1200 RECOMMENDED for IPv4?  Any reference to
> point to to explain?
> Section 5.1.4
> Figure 4 is useful as a “light” version of Figure 5, but there are one or two
> inconsistencies, or omissions.   In 5.2 you say there are omissions to Fig 5
> for simplicity, maybe the same note should be here too for Fig 4? e.g., there
> is no “black hole detection” path from “Search Complete” to “Base” (which I
> *think* is different to “PLPMTU confirmation failed”. I’d also suggest saying
> “PMTU Raise Timer” rather than just “raise timer”, or even use the proper
> “PMTU_RAISE_TIMER” in the figure.
> I also feel the “search complete” state is a little misleading; search complete
> is how you get to this state, not so much what it is, i.e., the search is
> complete, but this is the “DPLPMTUD steady state” or maintenance state, isn’t
> it?  From it, every so often you probe to see if you can raise the MTU, or test
> that the current MTU is OK, or if you detect a PTB you MAY trigger a probe.
> Maybe consider renaming this state?
> Last para of Base: spec - change “If this phase” to “if the Base Phase” else it
> could be read that “this” is the Search Phase.
> Sec 5.2
> In Fig 5, should there be a path from “Search Complete” to “Base” about PLPMTU
> Confirmation Failed, as per Fig 4?
> Definition of SEARCHING, 2nd para, I’d suggest adding “as described in Section
> 5.3” at the end.
> Definition of SEARCH COMPLETE - is it really always a “successful end”?   It
> may be that PROBE_COUNT = MAX_PROBES that gets you there.  Is that successful?
> Maybe just say after the completion, and not say successful?  Depends on the
> definition of success I guess :)
> Sec 5.3.2
> Maybe details of the advice here could be a separate Informational RFC?  I’m
> curious now.
> _______________________________________________
> OPS-DIR mailing list

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.