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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 10 February 2017 03:25 UTC

Return-Path: <brian.e.carpenter@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 8A2BC129551; Thu, 9 Feb 2017 19:25:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ALuGlDn1513o; Thu, 9 Feb 2017 19:25:41 -0800 (PST)
Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 74B04129562; Thu, 9 Feb 2017 19:25:41 -0800 (PST)
Received: by mail-pg0-x244.google.com with SMTP id 204so1932190pge.2; Thu, 09 Feb 2017 19:25:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=89bACYfdmEgrzwwGqzFQd3SxqiJopAme6V1HW2kHR44=; b=mVjv3EyVupQlq20a1Xd9fSLGEhmLmsibWdm1DMZgUEYh5Fefypuwbhp47tbQTIEgFp nqGp0wOgQpmExKymVKnOb+GgNBg3evy1caSzuoIYwPlnVDfLAJmb8/MqZUTVYc03uyUP UGMpm33AqxLHowgLXN0nTaf2JjVvC9oNKKFPqKJjtD6xSoZLhZzxTmOqd9ZHwp6Kvddx Hd7bS5Zl1irpz4101HC1m49T1lCx5fXoagVG3iIgrJuWv4SG0RCo0iJJsqDRLV0ajK78 D41wg1RDuFE9AKPO1jbXcJFsWJLedPLjXunf0sAXrkZFBq9KSdvTIYqMSB40QmN1fONd C0sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=89bACYfdmEgrzwwGqzFQd3SxqiJopAme6V1HW2kHR44=; b=tJhbVzVujApFtelBW3PJjWq4lx8o/wue5gZrHkd/Sr/Ie/AwbttO8M08zl/N8tpCNY 1KzFaohLxB0pHGkPgscja4J7nTD41bEwQTu4FWnm+kS43AyyLLDANaaioLp1fuWogz5z Us4YmuL7rJu1HFIUyT1GEUL1RpL9gmfWCMFductkP+6ZAAFH4Atyoms4kAd/O0lEn1t6 hMkLdv7rWj6Rk4favHAO1u0kEKTFjKTZqQyYrjzujrmzYWPtP5dy9yoz+LdR5qP4KGXk GqlgvpYszNPmCewDYjSlVVS7l1LvXutj0w26+hS93/6hWlJRnxDqefP644x0xeMRjO8t EX6A==
X-Gm-Message-State: AMke39nOPOoODV+f+nFt4zGWesN0NjB7AkFZr/xJH4uRWgUKlG9SOWfrDzqw3ykOAN1xZg==
X-Received: by 10.98.19.145 with SMTP id 17mr7590435pft.26.1486697140821; Thu, 09 Feb 2017 19:25:40 -0800 (PST)
Received: from ?IPv6:2406:e007:7ac3:1:28cc:dc4c:9703:6781? ([2406:e007:7ac3:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k184sm521569pgc.23.2017.02.09.19.25.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 19:25:40 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: Stewart Bryant <stewart@g3ysx.org.uk>, gen-art@ietf.org
References: <148665359396.20513.9749548375095869760.idtracker@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <2997d33f-3884-7831-50ed-1713c93b3867@gmail.com>
Date: Fri, 10 Feb 2017 16:25:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <148665359396.20513.9749548375095869760.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZHCMQJH1HupJYYmXEpbs99HpIJU>
Cc: ipv6@ietf.org, 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: Fri, 10 Feb 2017 03:25:42 -0000

Stewart,

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.

...
> It is concerning that the draft does not talk in any detail about
> how modern ECMP works, i.e. using the five tuple, and noting that
> the PMTU may be different depending on the transport layer port
> numbers.

Has this problem been analysed for, say, IPv4? And does the real world
contain ECMP setups with different MTUs on different paths?

> Given that a very large fraction of packets will traverse an MPLS
> network at some point, I am surprised that there is no text talking
> about the importance of providing support for this feature in the 
> MPLS domain. RFC3988 talks to this point, but is only experimental.

I don't understand. How does the fact that there might be some MPLS
segments along the path affect end-to-end PMTUD?

> 
> ======
> 
>    If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
>    could use the flow id as the local representation of a path. Packets
>    sent to a particular destination but belonging to different flows may
>    use different paths, with the choice of path depending on the flow
>    id.  This approach will result in the use of optimally sized packets
>    on a per-flow basis, providing finer granularity than PMTU values
>    maintained on a per-destination basis.
> 
> SB> How widely is flow-id supported in networks? I thought that the 
> SB> current position was that it was unreliable as an ECMP indicator
> SB> and thus routers tended to glean information from the packet themselves.

This is future-proofing. Agreed, usage today is limited.

(But it would be better to call it the Flow Label for consistency with other
recent RFCs.)

I think your other comments are all valuable.

Regards
    Brian