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

Stewart Bryant <> Mon, 20 March 2017 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 488281314EA; Mon, 20 Mar 2017 10:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Atz5LKr1yITU; Mon, 20 Mar 2017 10:00:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7BFF1314EB; Mon, 20 Mar 2017 10:00:10 -0700 (PDT)
Received: by with SMTP id u48so96587174wrc.0; Mon, 20 Mar 2017 10:00:10 -0700 (PDT)
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; bh=vr7v4fxuJaoyAL9kXg13j+/wZL4Jazj4Po+eAS00wDs=; b=qRF3CLZ8NJAnEmrZlx6UAki6ZAhzuDIJCPyhKRaRh2l9H6CIh9SCeKdYBVi6pjjSq1 wvE9a0QjG/oq5l2ycOKupRiWdfmQjSQbqxKYt6yY/xgqxufXzvsG/6n8vJ45LFq97+jS hB3ZlGGPNT9E3IqChH+XKrEb0PYPJZR2iEuHXZfTGuxzZVD8Ro1QRgEa3aGZ108dkIqw DwDR7WSv2JQknlUoaDPk0Fj74KzTD9mFF0HSroaRhScjmDTdsBS6Yr4lFkGA0VgSVErb h6nHu+720u0cyqOTBr+EWi83SSZljqMwe7hKaco+Pgey8Yu+0NsU7awvC01SIVe1RLHM DxJw==
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; bh=vr7v4fxuJaoyAL9kXg13j+/wZL4Jazj4Po+eAS00wDs=; b=eYMEH4QsOUTGE2clzRLyEqVsEYZv/Pr8Gjpk7I3aNkVcEv3V+96ejuCPWq46G3SHcO 0wMa0Jw2Mq0fOkN7SHDUgNI42i/Wfjd/mkgxFteCDEpZjmF2HB53UYOEnbEmJuo6Ywav O25oYE1jD44T388pl1CBdhMHflRP2VTy3Q+nGq+XXr52hUfd5cX9yUQKkLmjODjOZHEa RtKxFoH/XxiGqGAMPjVvtIWsxYtZSVcYI4uDqWUT2wWeyyGQypcFEGnRGIT828dUJlhJ 12afR4sj7kEQEcUTKfMWVi/Cq+P90nFg7PyK8X8ZoFNWVkVca/J9OIuObQOhft+Rmp34 OKzw==
X-Gm-Message-State: AFeK/H3ws7WzwniPcph4F+ZQiYaIOj/EuW4vUlB+xLuSBml7XQWYV3T9xW0knNh7ARQKKg==
X-Received: by with SMTP id v92mr29313481wrc.49.1490029208977; Mon, 20 Mar 2017 10:00:08 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id r8sm21421475wrb.33.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 10:00:08 -0700 (PDT)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: Bob Hinden <>, Stewart Bryant <>
References: <> <>
Cc: IPv6 List <>,, IETF <>,
From: Stewart Bryant <>
Message-ID: <>
Date: Mon, 20 Mar 2017 17:00:08 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------D16124D1E89C620CFECE780A"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Mar 2017 17:00:23 -0000

On 17/03/2017 21:56, Bob Hinden wrote:
> Hi Stewart,
> Thanks for the detailed review.  I am responding after reading the email thread that resulted, some issues were closed.
> Several of the reviews have suggested significant changes to this document.  The working group was trying to make a few changes to bring it into alignment with some changes to rfc2460bis (based on updating documents).  It was not attempting a major rewrite when advancing it to Internet Standard.  The alternative that the working group discussed was to file errata on RFC1981 and leave it to a future document update.

That might be the way to go.

At the end of the day it is an IESG decision, but I was somewhat 
disquieted by the number of issues and
comments raised across the set of reviewers.

When we elevate a document to standard we are saying that it represents 
a fully baked idea that has no
significant defects. The question given the level of comments is does 
this meet that bar?

> I don’t think many of these changes can be done and still advance it to Internet Standard. If we can’t advance the current document, then the w.g. may want to just do the errata and withdraw the advancement request.  Of course, if people want to work on a revision of IPv6 Path MTU Discovery, it would be welcomed, but it won’t be able to advanced to Internet Standard.
Given the level of discussion, I would think that the WG should 
seriously consider a revised version clearing
up the full set of issues raised in discussion.

Responses in line

Best Regards


> Comments below.
> Thanks,
> Bob
>> On Feb 9, 2017, at 7:19 AM, Stewart Bryant <> wrote:
>> Reviewer: Stewart Bryant
>> Review result: Almost Ready
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> For more information, please see the FAQ at
>> <>.
>> Document: draft-ietf-6man-rfc1981bis-04
>> Reviewer: Stewart Bryant
>> Review Date: 9/Feb/2017
>> IETF LC End Date: 1/Mar/2017
>> IESG Telechat date: unknown
>> Summary: This draft is on the right track but has open issues,
>> described in the review.
>> This review together with the lengthy discussion on the IETF list
>> suggest that this draft has a number of issues that need to be
>> addressed  before publication.
>> 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 think this was closed in the email thread.
>> Major issues:
>> Nits points out a number of faults with the document, but the only
>> one of substance is:
>> The text has a lot of RFC2119 language, but no RFC2119 declaration.
>> The document could use a thorough RFC2119 scrub
> Based on in an earlier another review, our AD suggested an update to Shepard Writeup instead of adding something to the document.  It says:
>     This document is an update to RFC1981 that was published prior to
>     RFC2119 being published.  Consequently while it does use "should/must"
>     style language in upper and lower case, the document does not cite the
>     RFC2119 definitions.  Since the changes in this update were very
>     limited, the w.g. concluded to not change any of this language.
This is really an IESG decision.

>> The document lists the three original authors one with an affiliation
>> change, but no email addresses. Has this been agreed with the
>> original
>> authors, and have arrangements been put in place for the RFC editor
>> to process auth48?
> I contacted the original authors and they didn’t express any interest in being involved in this update.  They haven’t participated in the IETF for many years.  I can contact them during AUTH48, or the AD can override this requirement for this document.

So long as you have an arrangement in place that is acceptable to the 
RFC Editor and IESG.

>> 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.
> I think this is out of scope.

So long as PMTU is bound to the five tuple (which I think it is), then 
the mechanism works, but given the
prevalence of ECMP (pretty much every packet going across the core will 
be sujected to it) I don't think
I agree that a discussion is out of scope.

>> 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 think this was closed in the email thread.

It was ruled out of scope on the basis that tunnel were out of scope, 
but this tunnel type does need
some special consideration, particularly as nearly every packet crossing 
the Internet goes across
this tunnel type a number of times in its passage.

For me it is ore a question of providing the best advice to the reader, 
rather than minimising change.

>> ======
>>    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.
> I think this was closed in the email thread.
>> ======
>>       Note: if the original packet contained a Routing header, the
>>       Routing header should be used to determine the location of the
>>       destination address within the original packet.  If Segments
>> Left
>>       is equal to zero, the destination address is in the Destination
>>       Address field in the IPv6 header.  If Segments Left is greater
>>       than zero, the destination address is the last address
>>       (Address[n]) in the Routing header.
>> SB> So this has the effect that a traffic engineered packet and
>> SB> a non-traffic engineered packet will have the lower of the
>> SB> two PMTUs. This was all harmless when source routing was a
>> curiosity
>> SB> as far as mainstream networking was concerned, but may be
>> SB> more of a problem as a result of the SPRING work.
> I think the onus is on SPRING to make sure it doesn’t break existing mechanisms.

.. or really doesn't break them any more than they discussion on this 
draft suggests that they are
already broken.

>> =======
>> 5.3.  Purging stale PMTU information
>>    Internetwork topology is dynamic; routes change over time.  While
>> the
>>    local representation of a path may remain constant, the actual
>>    path(s) in use may change.  Thus, PMTU information cached by a
>> node
>>    can become stale.
>>    If the stale PMTU value is too large, this will be discovered
>> almost
>>    immediately once a large enough packet is sent on the path.  No
>> such
>>    mechanism exists for realizing that a stale PMTU value is too
>> small,
>>    so an implementation should "age" cached values.  When a PMTU
>> value
>>    has not been decreased for a while (on the order of 10 minutes),
>> the
>>    PMTU estimate should be set to the MTU of the first-hop link, and
>> the
>>    packetization layers should be notified of the change.  This will
>>    cause the complete Path MTU Discovery process to take place again.
>> SB> Should that be an RFC2119 SHOULD?
>> SB> The impact of this advice is going to be a disruption to what
>> might
>> SB> be a critical service every 10 mins.
>> SB> Should there be some advice along the lines of noting the
>> SB> importance of service delivery as part of deciding whether to
>> SB> test for bigger PMTU vs improving efficiency?
>> =======
>> Minor issues:
>>    IPv6 defines a standard mechanism for a node to discover the
>>    PMTU of an arbitrary path.
>> SB> Do you mean "This document defines ....."? Otherwise this needs
>> SB> a reference.
> Will fix.
>> =======
>>    An extension to Path MTU Discovery defined in this document can be
>>    found in [RFC4821].  It defines a method for Packetization Layer
>> Path
>> SB> Rather than have the reader figure out what "It" is, perhaps
>> SB> s/It/RFC4821/
> The w.g. noodled on this text for a long time.  I think the “it” is clear, but will change to RFC4821.
>> =======
>>    Upon receipt of such a
>>    message, the source node reduces its assumed PMTU for the path
>> based
>>    on the MTU of the constricting hop as reported in the Packet Too
>> Big
>>    message.
>> SB> We should perhaps state up front that this procedure
>> SB> hunts for the worst case of the ECMP set associated with the
>> SB> ingress nodes PMTU classifier.
> I think getting into ECMP is out of scope for moving this to IS.

Yes, but I don't think you should set elevation to standard above 
providing the best advice, which
is what seems to be proposed here.

>> =======
>>    If a node receives a Packet Too Big message reporting a next-hop
>> MTU
>>    that is less than the IPv6 minimum link MTU, it should discard it.
>> SB> Should that be an RFC2119 SHOULD?
> See note above.
>> =======
>> 5.2.  Storing PMTU information
>>    Ideally, a PMTU value should be associated with a specific path
>>    traversed by packets exchanged between the source and destination
>>    nodes.  However, in most cases a node will not have enough
>>    information to completely and accurately identify such a path.
>>    Rather, a node must associate a PMTU value with some local
>>    representation of a path.  It is left to the implementation to
>> select
>>    the local representation of a path.
>> SB> Is it worth noting the five tuple since that is how a lot of
>> SB> load balancers work?
> I think getting into ECMP is out of scope for moving this to IS.
>> =======
>>    The set of paths in use to a
>>    particular destination is expected to be small, in many cases
>>    consisting of a single path.
>> SB> I am not sure that remains true in modern networks.
> Do we have any data on this?  I wonder if there will be much difference in the PMTU in this case.
In a well managed network the point is probably moot since all paths 
should have the same PMTU except
under error conditions, but the path set can be quite large, and 
certainly more that a single path.

>> =======
>>    One approach to implementing PMTU aging is to associate a
>> timestamp
>>    field with a PMTU value.  This field is initialized to a
>> "reserved"
>>    value, indicating that the PMTU is equal to the MTU of the first
>> hop
>>    link.  Whenever the PMTU is decreased in response to a Packet Too
>> Big
>>    message, the timestamp is set to the current time.
>>    Once a minute, a timer-driven procedure runs through all cached
>>    values, and for each PMTU whose timestamp is not "reserved" and is
>>    older than the timeout interval:
>>    -  The PMTU estimate is set to the MTU of the first hop link.
>>    -  The timestamp is set to the "reserved" value.
>>    -  Packetization layers using this path are notified of the
>> increase.
>> SB> Such detailed implementation advice is uncommon in modern RFCs. It
>> has
>> SB> the disadvantage of de-facto standardizing something that should
>> be left to
>> SB> the innovation of the implementer.
> Can you point to any harm this has caused?  It is very widely implemented.

It tends to result in people treating the example complete with any 
artifacts as normative. Which gives
implementors less scope for optimisation, and can result in restrictions 
beyond the true intent of the

Now I am not sure if there is a problem here, but I think it is bad 
practise in general.

>> =======
>> 5.4.  TCP layer actions
>> SB> TCP implementations have moved on a lot since this section was
>> SB> written. Is this still current best practise?
>> =======
>> 5.5.  Issues for other transport protocols
>>    Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed
>> to
>>    repacketize when doing a retransmission.
>> SB> How much TP4 is there going over IPv6? Doesn't this example
>> SB> show the IETF as not being in the modern age?
> I have no information one way or another.  I have heard there is some TP4 on airplanes, may they will move it to IPv6 :-)
It really depends on whether the goal is to elevate what was originally 
written or to provide best current

>> =======
>> Nits/editorial comments:
>>    upper layer         a protocol layer immediately above IPv6.
>>                        Examples are transport protocols such as TCP
>> and
>>                        UDP, control protocols such as ICMP, routing
>>                        protocols such as OSPF, and internet or lower-
>>                        layer protocols being "tunneled" over (i.e.,
>>                        encapsulated in) IPv6 such as IPX, AppleTalk,
>> or
>>                        IPv6 itself.
>> SB> Everything in the list above is in the well known list, except
>> SB> IPX, so technically it needs expansion. However it might be nice
>> SB> to use some modern example in common use.
> I will add a reference to IPX.  The best reference I have found to IPX is:
>         Novell, Inc., "Advanced NetWare V2.1 Internetwork Packet Exchange
>         Protocol (IPX) with Asynchronous Event Scheduler (AES)", October
>         1986.
> Please suggest something better.

I stand by my original view that we should use modern examples and leave 
it to the IESG to
decide which path they prefer.

>> =======
>>    link                a communication facility or medium over which
>>                        nodes can communicate at the link layer, i.e.,
>>                        the layer immediately below IPv6.  Examples
>> are
>>                        Ethernets (simple or bridged); PPP links;
>> X.25,
>>                        Frame Relay, or ATM networks; and internet (or
>>                        higher) layer "tunnels", such as tunnels over
>>                        IPv4 or IPv6 itself.
>> SB> Technically X.25 needs a reference, since it is not "well known”
> Will add a reference, if you think it is necessary.
>> =======
>>    path                the set of links traversed by a packet between
>> a
>>                        source node and a destination node.
>> SB> Is it a set of links, or a set of links and nodes?
> I think the current text is OK.
>> ========
>>     the value of MMS_S, the "maximum send transport-message size".
>> SB> The modern convention is full-name(abbreviation)
> I don’t follow this.

A really minor point. A RFC usually expresses this as

    the maximum send transport-message size (MMS_S), but that is a house style thing.

>> ========
>>    The Sun Network File System (NFS) uses a Remote Procedure Call
>> (RPC)
>>    protocol [RPC] that, when used over UDP, in many cases will
>> generate
>>    payloads that must be fragmented even for the first-hop link.
>> This
>>    might improve performance in certain cases, but it is known to
>> cause
>>    reliability and performance problems, especially when the client
>> and
>>    server are separated by routers.
>> SB> Perhaps this should point to RFC7530 (the current NFS Spec),
>> assuming
>> SB> the behaviour description is still correct.
> Will do.
>> =========
>>    The former can be accomplished by associating a flag with the
>> path;
>>    when a packet is sent on a path with this flag set, the IP layer
>> does
>>    not send packets larger than the IPv6 minimum link MTU.
>> SB> We do not normally give this level of implementation advice
> I think it varies a lot.

>> ========================
> _______________________________________________
> Gen-art mailing list