Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
Stewart Bryant <stewart.bryant@gmail.com> Fri, 10 February 2017 10:20 UTC
Return-Path: <stewart.bryant@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 5CB87129487; Fri, 10 Feb 2017 02:20:42 -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 HaH7n7hUjY3r; Fri, 10 Feb 2017 02:20:41 -0800 (PST)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::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 BA3E6128E18; Fri, 10 Feb 2017 02:20:40 -0800 (PST)
Received: by mail-wm0-x241.google.com with SMTP id u63so6667232wmu.2; Fri, 10 Feb 2017 02:20:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dBektC9JHSm51JDgOcNkfp/fJv0IMVc5kIf7BSf0igA=; b=K2i3aNiBcyPWxLBpT2wMcFXcJ82i5AeU0a/hjguTWeI+mTasyOJg8I0hzVXgLAmjec gMvlO+H8Fj32dmi8eXGeCzHaox9W355L1AC2ujrcxKNDGreqTVNuyCYQyXqbzPvHBPnu kboriHMn2rJWhb/vKSncm0jSsYoomgHkti7Z9gfyq11IMF1S/RK9gS2MULZSymplcwKf bmCvTtQaBO0YJeMF9Wqdcx/h6hxQXELKasUSJF1fLgsqkd776B6JlU6cM4fepAB42O1e lj8HOBEiuIOgsBxqrBDlNkpdW9Magn4UsGisXwPhrUEZGw2T+7UzRXc0jBarqtSbqPlS 1q1A==
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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dBektC9JHSm51JDgOcNkfp/fJv0IMVc5kIf7BSf0igA=; b=nlaRx13bQZEoIkd0GgNjNQqpOlndtS1BaZKG5OxXyN7+UHvag8jMdsNPQto/vPfTN6 mDnj26Y6SRW/T2wgStfP870m58KhLLyz+nmManioBTCZ06UcL/tjgqJLkdDJD+ZzQQkG 8IXStWz3hMhXkJkHH90IMrqaQ/h9gonO52pG1lRaZsNmezhjxlWkWtvoNg5vI1uV/IMX 4qtJ01fmZXo8KZzvCjj1Ep9nN69MBs/T6sBycNd+qkRu+aHDsy4hgg7zl/Mms1GDFwJ5 cToy9jbEe2SqspHsbsPeM1crIPrEDBJowz7v2/pt2fAq8v8pzvSaSD0Mk+3NzfIzBU93 kq4w==
X-Gm-Message-State: AMke39nCU+NcCxK6IIzKoUx1mEKa7Tdalz1mjRuCMdqS5VnS5oC6mEtYb2jL8hsActNZag==
X-Received: by 10.28.224.213 with SMTP id x204mr6399819wmg.82.1486722038995; Fri, 10 Feb 2017 02:20:38 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id n13sm1976907wrn.40.2017.02.10.02.20.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 02:20:38 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: Brian E Carpenter <brian.e.carpenter@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>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <b9dfd941-0eba-c257-fef4-2f5e6bbd82a8@gmail.com>
Date: Fri, 10 Feb 2017 10:20:35 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <2997d33f-3884-7831-50ed-1713c93b3867@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mz5VZmIkvrwWUK8TRgheYp2y8y4>
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 10:20:42 -0000
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 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. 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 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. 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? > >> ====== >> >> 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? I don't know, but I do know that the mainstream ECMP approach is the five-tuple. 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. > > 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