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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 14 February 2017 16:25 UTC

Return-Path: <Fred.L.Templin@boeing.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 B2940129641; Tue, 14 Feb 2017 08:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jwtTfMG-yEXl; Tue, 14 Feb 2017 08:25:28 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B976129696; Tue, 14 Feb 2017 08:25:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1EGPRJ3051436; Tue, 14 Feb 2017 09:25:27 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1EGPGg0051233 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 14 Feb 2017 09:25:16 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 14 Feb 2017 08:25:15 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 14 Feb 2017 08:25:15 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Stewart Bryant <stewart@g3ysx.org.uk>, "gen-art@ietf.org" <gen-art@ietf.org>
Subject: RE: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
Thread-Topic: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
Thread-Index: AQHSg01qd1t1l5P4r0CAXezaoK6tiaFijiOA///QkXCABnBjgP//3WSwgACNdoD//3ylEA==
Date: Tue, 14 Feb 2017 16:25:15 +0000
Message-ID: <f4f81574e09e45169438d39afeb83369@XCH15-06-08.nw.nos.boeing.com>
References: <148665359396.20513.9749548375095869760.idtracker@ietfa.amsl.com> <2997d33f-3884-7831-50ed-1713c93b3867@gmail.com> <b9dfd941-0eba-c257-fef4-2f5e6bbd82a8@gmail.com> <078b28a9a26540da9e4caaba4c436cd3@XCH15-06-08.nw.nos.boeing.com> <440c60d3-0687-c7f1-f8b6-19620e6f618a@gmail.com> <6cb665e0a2244dae93e1b5b91bd9495a@XCH15-06-08.nw.nos.boeing.com> <fce8c0ef-25b7-9ba7-a5bf-9b5d7f2b19fc@gmail.com>
In-Reply-To: <fce8c0ef-25b7-9ba7-a5bf-9b5d7f2b19fc@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rNskhxioqaW_ABKVp1bRuqKYPUY>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-6man-rfc1981bis.all@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: Tue, 14 Feb 2017 16:25:29 -0000

Hi Stewart,

> -----Original Message-----
> From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
> Sent: Tuesday, February 14, 2017 8:13 AM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>;; Brian E Carpenter <brian.e.carpenter@gmail.com>;; Stewart Bryant
> <stewart@g3ysx.org.uk>;; gen-art@ietf.org
> Cc: ipv6@ietf.org; ietf@ietf.org; draft-ietf-6man-rfc1981bis.all@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 
> 
> 
> 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
> provisioned
> 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.

So, that would leave us with RFC4821 plus per {session,destination}
probing instead of just per-destination probing. Or, just stick with the
IPv6 minMTU (1280)?

Thanks - Fred
fred.l.templin@boeing.com

> > 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
> providing
> active email addresses.
> 
> - Stewart
> 
> >
> > Thanks - Fred
> > fred.l.templin@boeing.com
> >
> >> - 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
> >>> fred.l.templin@boeing.com
> >>>
> >>>> -----Original Message-----
> >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Stewart Bryant
> >>>> Sent: Friday, February 10, 2017 2:21 AM
> >>>> To: Brian E Carpenter <brian.e.carpenter@gmail.com>;; Stewart Bryant <stewart@g3ysx.org.uk>;; gen-art@ietf.org
> >>>> Cc: ipv6@ietf.org; ietf@ietf.org; draft-ietf-6man-rfc1981bis.all@ietf.org
> >>>> 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
> >>>> ipv6@ietf.org
> >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >
>