Re: Manual PMTUD [was ...rfc2460bis-08]

Robert Raszuk <robert@raszuk.net> Sat, 18 March 2017 09:15 UTC

Return-Path: <rraszuk@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 30EF5124BFA; Sat, 18 Mar 2017 02:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Yw2S1CMyqQtj; Sat, 18 Mar 2017 02:15:56 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 E8ADC1243FE; Sat, 18 Mar 2017 02:15:55 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id m27so45452664iti.0; Sat, 18 Mar 2017 02:15:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=n1AaHx6sk3A6B/NvNTJIFI7OWP2IO3naczX1bMgWI6s=; b=NK2WLKDVwqnAN1z/2r067ikTKgQKaX60j3B4IEux+MNEv1hNEO9MV9hbJZ9nKXUpck IzFkHKKmci9mQS97YS8w+bqoe0XVJBk8aA/9aVcVXHqfwTenaFL3Z+5adLROgHbfPPjT QG+8Lc2frs1jFOR+67/LJEmDW4d+1bQVuOdaH/179u/YFGLfrDQjnUXFIiU9fPthZQsf trk1PP7To6zWqVnBZeWwyyr+WJkoLSZevgy4wSX511nXPWPp9jnfaJmGjp2j+V3wev/4 x7C5V6FohAOqDhw7drhOGmpYYr/zenV4f7JDrZjguXxUrecGocScFK7BHSjG9kthwFG1 ZVXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=n1AaHx6sk3A6B/NvNTJIFI7OWP2IO3naczX1bMgWI6s=; b=iGKTVrzy4MbVl8nCn+3YqHnf9I1vr9g+TxqUNEwoTApmTTafBBt6N9mrF3M9N7iOV9 PI/YgSJBuDWWa7IRemO6OM88eNwcPAGMiIKoz8eJw8z62kxd+Yu5dEYa8E8RLGefGn4R 7tDeencmYFbW/eBSPWBbnIM00vkDHE4kcP9rLwHAGPMUqvgnh0DX/y8vUB1UzYN4EKvK EAgq/LSF32cV0MhkY/G+t0kiXurD8iovHgp1G+H12Vpvk2pKzG/bTVVPToKz9oymqkNA PU/NDD0/BFC3raXPxE8k8id0oz3awpDwEibOGybCUOfJJEbFKuWw5cK/4Bo/UNQvasFs xLVw==
X-Gm-Message-State: AFeK/H3Pqam3Iay1L1T4+ga3cXq06S42+A9P9v22KEw5ocGf35SkMu9pWQE2trNuVni13lHhpuE/Hp2fgj2Mzg==
X-Received: by 10.107.7.29 with SMTP id 29mr19118277ioh.57.1489828555308; Sat, 18 Mar 2017 02:15:55 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.35.207 with HTTP; Sat, 18 Mar 2017 02:15:54 -0700 (PDT)
In-Reply-To: <618152cf-b097-6d39-e3eb-84b676fb56b7@gmail.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <A67E1C07-282B-4422-A2FF-86F6CACBD775@cable.comcast.com> <ab7c95a5-9776-24b5-7c26-4c5987d4c948@isi.edu> <ed2f5144-52fb-dda5-1fb4-62be1625b341@gmail.com> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <DE16D91D-AE7B-4D3C-B8EA-0CB644FB96BD@cable.comcast.com> <CA+b+ER=6dXLiwvLJa84uvpVeH0daGnZ-06P16JD0UutTrbUYyA@mail.gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <CA+b+ERnL6FjPVRZgVzoay81gX-SkujkgTfd6EB3PM1Sq_HM9yA@mail.gmail.com> <618152cf-b097-6d39-e3eb-84b676fb56b7@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 18 Mar 2017 10:15:54 +0100
X-Google-Sender-Auth: Q2oqUGQEA1mQkm8lgfpYRfkjdmE
Message-ID: <CA+b+ER=Zwy3ODOfkVNrsvK0S946111f6prSpXLM+e=6u8-W_qA@mail.gmail.com>
Subject: Re: Manual PMTUD [was ...rfc2460bis-08]
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: "Leddy, John" <John_Leddy@comcast.com>, Stewart Bryant <stewart.bryant@gmail.com>, Tim Chown <Tim.Chown@jisc.ac.uk>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="001a113ea6f0d0ed54054afdbd03"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0k2CvW2Tm24CRYn04EvuTh8bxuk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 18 Mar 2017 09:15:58 -0000

Hi Brian,

On Sat, Mar 18, 2017 at 2:10 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> > I can use
> > today SRv6 features in my data centers where I consistently know that all
> > interfaces are set for jumbo frames and where hopefully I do not need to
> > worry about MTU since hosts have much lower max MTU configured.
>
> Exactly. That's not the Internet. Internet Standards are for the Internet,
> hence I believe that the AD's decision is the correct one.
>


​Well I don't know .. Protocols are used both in the open Internet and in
the contained ​environments. Hence IANA allocations and draft progress
should be encouraged regardless if something is to be deployed in the
Internet or not.

Now as customer I do encourage multi-vendor networks even for closed
RFC1918 private WAN, MAN or DCs.

If we just drop and position IETF to work on "Internet" only use cases
where would interoperability of routing protocols and beyond fall under ?
Which SDO ?


(How would you feel about an extension header that MAY be deleted
> by an intermediate node, and MUST be deleted if the next hop's link
> MTU is too small?



​Well SRH can be applied both as a mission critical or optimization. If it
is an optimisation ​indicated in the packet by a flag I would be fine to
remove it if it does not fit to the MTU of the link.

If it is however "MUST HAVE" for a given flow I would rather see a packet
drop then to continue forwarding without it.

Both such events should indeed be signaled to the "owner" of the SRH or any
other extension header either inbound via for example ICMPv6 or maybe by
some other targeted message or indicated out of band (via logging to
syslog) - applicable to single administration domain.

​Kind regards,
Robert.​