Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Suresh Krishnan <suresh.krishnan@gmail.com> Sat, 11 February 2017 06:42 UTC

Return-Path: <suresh.krishnan@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77681294AD; Fri, 10 Feb 2017 22:42:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7RJZAQS5Ouw; Fri, 10 Feb 2017 22:42:46 -0800 (PST)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E20E127601; Fri, 10 Feb 2017 22:42:45 -0800 (PST)
Received: by mail-vk0-x229.google.com with SMTP id k127so39066542vke.0; Fri, 10 Feb 2017 22:42:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OVjo0u3qVPxNT/T53/VeGKf8JIGySnqBdG62iqs+J74=; b=Eu7grB2SCiiDM0Ed+x2HDbGy7avzpb5sMeFvDgvWkT7dO+CkqWqsDkXUOFYErb1NBN q753ZqU3R86ypQ03vXnGU1NTtmupD4hhQwQ8Zo1ct/KO+2nE4DkxjHoEp3TmdLNPstP+ 6t6FLLvwDT5BaCVrSpRi/QDtYv0J7wEGOLXNUw0IIlJ1ddcT+EHII2SwuzT4M0qAbm5V vxyJ2IrI5bqRlIi41BHmuJufgbXTGGKkCjQylKcMRyT4jj+LM6pqE/OxI3miwLh1Yy4J 79YVnnPi5kFnJaplOqhASVjsS22TVpObeisQGR0W8IYHvoOKTX5bSWuxpMcz1e3hLHxs HqZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OVjo0u3qVPxNT/T53/VeGKf8JIGySnqBdG62iqs+J74=; b=UPJWFI48C/3RdRSF2ZvxlzMaTcsBQ5Z/9FbCpMlOCk25DLK9hNCMgSBXtLWPhkNPhH l7H1kUjPFqPkQjWITlbbHW42Ffn6HuOr8eJGSIJCXvBDV28klKKhSbOUUCSYHo2VrLfv jzYci1hG6uXiMLOoKKzZf8aDcIsOx75ki62GeVFXKxDy1zTr/SyXiO3iHqRXk0/bu2FT XnRMI7AmdLoFDAgREGhe6AYoyefvKYQex73+cu8hYoau/t1go27IsBmJCarodB0Xrosp FzlSCvMSNpT6Dn3COrgAFaAQnJWz7bc9WymyY7dsbmH7Xd6F/KRZBneuOFCbUDPsR5uG uN1w==
X-Gm-Message-State: AMke39kZxCu3ENJxge8ivqEuG8TaNFeOCRR7LtRRYh5v5bCPmf1uPshcxP5UIEu8S+Ey1Wigy36gn3GF8havcQ==
X-Received: by 10.31.128.78 with SMTP id b75mr6185594vkd.174.1486795364824; Fri, 10 Feb 2017 22:42:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.14 with HTTP; Fri, 10 Feb 2017 22:42:44 -0800 (PST)
Received: by 10.103.49.14 with HTTP; Fri, 10 Feb 2017 22:42:44 -0800 (PST)
In-Reply-To: <CACL_3VEyOriSb6fjvGbYvG5a3gKOYPEe89-w7B9C_A5y_A9O9Q@mail.gmail.com>
References: <CACL_3VEyOriSb6fjvGbYvG5a3gKOYPEe89-w7B9C_A5y_A9O9Q@mail.gmail.com>
From: Suresh Krishnan <suresh.krishnan@gmail.com>
Date: Sat, 11 Feb 2017 01:42:44 -0500
Message-ID: <CA+MHpBougeQHCeajjpuGWj2N7RSsum80X6yy7nxzJzXfiDn+3Q@mail.gmail.com>
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: "C. M. Heard" <heard@pobox.com>
Content-Type: multipart/alternative; boundary=001a1142a40492fece05483b8561
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fvR_4NfhB2u86DlUQLSJJ9FvwhA>
Cc: 6man WG <ipv6@ietf.org>, gen-art@ietf.org, Stewart Bryant <stewart@g3ysx.org.uk>, IETF <ietf@ietf.org>, draft-ietf-6man-rfc1981bis.all@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Feb 2017 06:42:48 -0000

Hi Mike,

On Feb 10, 2017 11:30 PM, "C. M. Heard" <heard@pobox.com> wrote:

On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> On 10/02/2017 23:20, Stewart Bryant wrote:
> > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > On 10/02/2017 04:19, Stewart Bryant wrote:
> > > > I wonder if we would best serve both our future and our heritage
> > > > if we declared RFC1981 as historic, and either left the idea there,
> > > > or declared it as historic and wrote a new text from a clean start?
> > >
> > > I don't see that. It's a stable, widely deployed, interoperable
> > > mechanism. That is rather orthogonal to the issue that has been
raised,
> > > which is that faulty ICMPv6 filtering blocks it on many, many paths
> > > across the Internet.
> >
> > I will not debate whether it is faulty or not,
>
> It's faulty by the standard of RFC4890 (which is Informational).
>
> > but it seems that in practice the Internet breaks the mechanism.
> > However it breaks it is a way that seems disruptive to some user
> > traffic. The document is really guidance one how hosts might use
> > ICMP for optimization, and arguabl[y] need not be a standard at all.
>
> I think that's a mischaracterisation of the mechanism (and the draft).
> PMTUD is not an optimisation. Without it, you get black holes.

Actually, no. You do not have to use PMTUD to avoid black holes.
Other options include:

- Send packets no larger than 1280 bytes (this is always an option)
- Use PLPMTUD (for transports that do their own packetization and
  that can detect packet loss)


How does this work for UDP?


> > My remark about heritage is that this vintage draft is very much a
> > product of its time, and really needs modernizing, and after
> > modernizing ought to look quite different, and thus maybe we
> > should employ a procedure other than a simple replacement.

I am afraid that I have to agree with this. Classic PMTUD by itself
is today not enough, but it can be a very useful optimization to
augment other techniques.


OK.


> It's proposed for Internet Standard. That means it must replace the
> PS document and must specify the same thing, plus corrections,
> minus unused features.

All true, and my conclusion is that is it should not be promoted to IS.


What criteria for advancement to IS do you think are not met by this
document?

I would have no problem with republishing at PS to correct the errata
and aid the eventual advance of RFC 4821 (PLPMTUD).

If this document does go forward, the words in Appendix B (Changes
Since RFC 1981) relating to RFC 4821 should be removed, since
there was no mention of RFC 4821 in RFC 1981.


Not sure I understand your concern. This is a change log since RFC1981. And
it is a fact that the reference to RFC4821 was added into this draft. Can
you clarify?

Thanks
Suresh