Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 10 February 2017 19:45 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 6DE3B1295A2; Fri, 10 Feb 2017 11:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_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 MOxZ3dYvUwbD; Fri, 10 Feb 2017 11:45:37 -0800 (PST)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 1E7E5129540; Fri, 10 Feb 2017 11:45:37 -0800 (PST)
Received: by mail-pf0-x241.google.com with SMTP id 19so3069934pfo.3; Fri, 10 Feb 2017 11:45:37 -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=swUDx54phvfF0lOJ8hCltKAaJz4Je2hRCpTLONbFpxE=; b=lZ9rxZpcxBgBycFYjYudiE8smtLoEKuo6uJhdWncUj/jY9FvtZw6xMUyYHVkBFB5wN WmITLo/bmNhptJKVrNYYpyse9pHvJo3/hfXRY/3FnnOa14cRHYqb6B7fAftGxEvb81t3 jm92G8ndxKQmjm7yXa3F7hNw4xiAjqw5iQomRGcjGm5WkzloTZiY3eGMSdVVM0Z4pMUx j3Cu6vUGU4ttPIbmrnIcYg+9yKqJpXCOwfoSSsVlV4O8BEVrVQpJFVBn4zeEQ7CNbhMs ObPnlEloaM10GI8y0ERq/7m4lw+IOIcADRscnbA8oSJ71Dr/wQrkPweoQIA7ubMSpVFM qibg==
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=swUDx54phvfF0lOJ8hCltKAaJz4Je2hRCpTLONbFpxE=; b=Rdm/4tHvDHgDGlet7UAb8LXOK728NTmvWqdLXMgoCFWi2fI0dbkVu2/vzJiX+W5uHU e84Gfpl5ebz2862DZoH9LPEV5YelHCZSgc/0m9E8G8pBOf1fNVx8J3eTUWHMYqaUZwPM vhdYqir2Bvh1OmzwGVc/oodKRNUkiHgRCmvo1sDPgkxkmbq/k5Ic+qOEaxbpOTjIdWod sQt72/GTL+tl+tMZ9Nj9JLXoFloIgOuHt3vupm0XFT51C/d8j1K0TroY21PzbUUA2/cb qyILRpBQwb3+TcE/T6Szv0aVbSQR3XHnt2JxZITs9Drmy+fA2NVlG51HUMkA/qtrfFeu 5cmQ==
X-Gm-Message-State: AMke39nbKoqJl/w80yPTzdf2nru48VoswBBke/MHKhfCEsZhsKIh+9ozCvU8xEgxgyX63w==
X-Received: by 10.99.109.143 with SMTP id i137mr12712107pgc.11.1486755936371; Fri, 10 Feb 2017 11:45:36 -0800 (PST)
Received: from ?IPv6:2406:e007:769c:1:28cc:dc4c:9703:6781? ([2406:e007:769c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g70sm7160051pfb.50.2017.02.10.11.45.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 11:45:35 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: Stewart Bryant <stewart.bryant@gmail.com>, Stewart Bryant <stewart@g3ysx.org.uk>, gen-art@ietf.org
References: <148665359396.20513.9749548375095869760.idtracker@ietfa.amsl.com> <2997d33f-3884-7831-50ed-1713c93b3867@gmail.com> <b9dfd941-0eba-c257-fef4-2f5e6bbd82a8@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <9a1a0a47-d8fd-5cf9-0244-7ce624d58470@gmail.com>
Date: Sat, 11 Feb 2017 08:45:41 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <b9dfd941-0eba-c257-fef4-2f5e6bbd82a8@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pVheVRX3WqL2wsnjBo2XL9fhKrc>
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 19:45:38 -0000
On 10/02/2017 23:20, Stewart Bryant wrote: > > > On 10/02/2017 03:25, Brian E Carpenter wrote: >> 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. > > I will not debate whether it is faulty or not, but it seems that in It's faulty by the standard of RFC4890 (which is Informational). > 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 arguable 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. > > 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. 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. >> ... >>> 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? > > I don't know if anyone has looked. Since the mechanism is > self-correcting albeit > with some disruption to user traffic it looks to the application and the > application > user, just like the Internet not working for a few moments. > > In a well managed SP network there should not be, but neither should there > be asymmetric path costs, but there are. The less well manage private > networks are less well managed. > > >> >>> 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? > > The point that RFC3988 makes is that MPLS looks like a single hop to IP > and the > PE has to fragment or has to reply with an ICMP error message to support > PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to > result > in the right response at the end node. > > My point is that the draft is silent on the subject, and perhaps it > should not be. Well, in general it's silent on tunnels. They have to emulate links, as stated in section 2. I still don't see why an MPLS tunnel is a special case. > > However your question make me ask a further question. The draft is also > silent > on NATs. Is there any advice needed for people designing and configuring > NATs? Yes, for NAT64/NAT46 - in RFC6145. For NAT66, the advice is "don't". >> >>> ====== >>> >>> 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.) > > Well the question is whether it is simply limited today, or broken today > in a manner that > is irrecoverable? Nothing's broken. It's just underused. > I don't know, but I do know that the mainstream ECMP > approach is the five-tuple. Sure, but see RFC6438 for some of the difficulties that causes with IPv6. > There is something akin to the flow label being > deployed in MPLS. However > what distinguishes the MPLS Entropy Label is that it is inserted (and > removed) by the > service provider and is therefore trusted by the service provider. Exactly the same for ECMP tunnels, in RFC6438. Guess what, my co-author was from a provider. Brian >> >> I think your other comments are all valuable. > Thank you. > > Stewart > . >
- Review of draft-ietf-6man-rfc1981bis-04 Stewart Bryant
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Brian E Carpenter
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Stewart Bryant
- RE: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Templin, Fred L
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Brian E Carpenter
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… C. M. Heard
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Suresh Krishnan
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… C. M. Heard
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… otroan
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Mark Andrews
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Eggert, Lars
- RE: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Templin, Fred L
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Stewart Bryant
- RE: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Templin, Fred L
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Stewart Bryant
- RE: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Templin, Fred L
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Stewart Bryant
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… otroan
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Fred Baker
- RE: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Templin, Fred L
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… otroan
- RE: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Templin, Fred L
- RE: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Templin, Fred L
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… james woodyatt
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Brian E Carpenter
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Joe Touch
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Joe Touch
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Joe Touch
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Stewart Bryant
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Joe Touch
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Brian E Carpenter
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Joe Touch
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Stewart Bryant
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Joe Touch
- Re: Review of draft-ietf-6man-rfc1981bis-04 Bob Hinden
- Re: [Gen-art] Review of draft-ietf-6man-rfc1981bi… Stewart Bryant