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

Stewart Bryant <> Tue, 14 February 2017 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F41F11294BF; Tue, 14 Feb 2017 08:13:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nFU-s9xb1fqP; Tue, 14 Feb 2017 08:13:06 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E14212967F; Tue, 14 Feb 2017 08:13:06 -0800 (PST)
Received: by with SMTP id r18so4282887wmd.3; Tue, 14 Feb 2017 08:13:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=aFYRlUp+zT3cRyTuc5QfAuwZevJdSQ7XkY44NGrREJA=; b=o57p4trTCV2S669d9jhozhYNhwjISSEcqt9PDfPy4SZEQhnEDRzaG3BQCTbT3ldCVy UOFvNt57Hf3MDqsOygpLzAXEMQJWuZpQwT/udHPIbtB/Wt9myTg4XPNg5QW1MbzBKdBO 99C4LK3c8WEV1sno5IMp8d7hF21n/1w25Qq/jQEju4y3BTBPRVk4JeQw+zxrtcyMfDwr 3NHKB4MkiraOcwihRyhZg95sV1AvryL4hNgRLKvE5zV2HwGp3qH11NEYu7iiqRPLfI8A BSThZ2Y3FMsQ3KGU1EOwl5Hx5mDnNs9O3q5/+5Xdf9oNbbkPipw9qxyGzHbkq06dnB6M fNCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=aFYRlUp+zT3cRyTuc5QfAuwZevJdSQ7XkY44NGrREJA=; b=gEMc2K3hAhtZh0szOU/we4ZTh+wNEiOhTf+l34g6atafSz8cUrRLFqJVezQ2vboVRN Cdfi+Vx6oS+2OIqZL+ezlz94aWYOy9eJ77dkT22IJaKTIHRgTYzgissPSThvCme2OLgl udsNDV+0SXFMBEaxH/lgGGb2m3kgztRduunFCxdLIO1fECkQh1k19NewSCnC1F3S6IKj 12B9jF9GTHmpAcKiHO3Ib3oB4wa9BmVH2Ae/SyoZuxTuy0UUtIXyhdyhbzrWwfzzG9EH 7XxcsrFtEJ4zxqhd56lYXjhOq1NIA+ZO09Ca5Ws9OhLfGkOs1FhnFLFsVctZ7j0IM+C8 jEiA==
X-Gm-Message-State: AMke39m4LeP0DrOo8ubEUKy7K7IgS/wuUoWggBXoSDVngweSMbPLBonoAzS6wIBmz+uZZg==
X-Received: by with SMTP id j74mr4122365wmf.76.1487088784984; Tue, 14 Feb 2017 08:13:04 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 8sm4414020wmg.1.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 08:13:04 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: "Templin, Fred L" <>, Brian E Carpenter <>, Stewart Bryant <>, "" <>
References: <> <> <> <> <> <>
From: Stewart Bryant <>
Message-ID: <>
Date: Tue, 14 Feb 2017 16:13:03 +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: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Feb 2017 16:13:09 -0000

On 14/02/2017 15:50, Templin, Fred L wrote:
>> As to you first point remember that the convergence process disrupts the
>> traffic flow as it does so, and that this will repeat every 10 mins as
>> it tries to re-optimise.
> Yes, you are right. So, even in the case of RFC1981bis it might not be a
> good idea to store discovered MTUs in the network layer when there
> is ECMP in the path. (Which could be any time at all.)

Yes, I think if you really care about disruption due to packet loss your 
best bet is
to go with the minimum supported MTU.

Forwarding performance is not a issue these days, and core link are over 
so you have to wonder how important the efficiency gain is in practice.  
The efficiency
gain produced by this protocol in most networks (1276 vs 1496) is only 
about 15% anyway.

> You briefly mentioned the authorship in your earlier post. As you well
> know, the corporate affiliation of two of the authors no longer exists.
My concern was that some authors cannot take part in Auth48 due to not 
active email addresses.

- Stewart

> Thanks - Fred
>> - Stewart
>> On 10/02/2017 15:38, Templin, Fred L wrote:
>>> Hi, about ECMP I think RFC1981bis should be OK even if ECMP is used in the
>>> network as long as ICMP PTBs are not blocked. RFC1981bis will eventually
>>> converge to the minimum MTU of all paths in the multipath, and so it is
>>> still OK to store the MTU in the network layer where it would be shared
>>> by all flows.
>>> ECMP does present challenges for RFC4821, however. If a first transport
>>> session discovers a large MTU and shares it with a second transport
>>> session, the second session may take a very different path where there
>>> is a smaller MTU and encounter a black hole. IMHO, it might be a good
>>> idea to file an erratum to RFC4821 explaining how ECMP might cause
>>> problems if discovered MTUs are shared between sessions.
>>> Thanks - Fred
>>>> -----Original Message-----
>>>> From: ipv6 [] On Behalf Of Stewart Bryant
>>>> Sent: Friday, February 10, 2017 2:21 AM
>>>> To: Brian E Carpenter <>; Stewart Bryant <>;
>>>> Cc:;;
>>>> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
>>>> 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
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> Administrative Requests:
>>>> --------------------------------------------------------------------