Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Ole Troan <otroan@employees.org> Thu, 02 August 2018 20:06 UTC

Return-Path: <otroan@employees.org>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D87130E04; Thu, 2 Aug 2018 13:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lgq_WuYqnBLL; Thu, 2 Aug 2018 13:06:43 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8151292AD; Thu, 2 Aug 2018 13:06:43 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id DB82A2D4FFB; Thu, 2 Aug 2018 20:06:42 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id AA09C243F3E; Thu, 2 Aug 2018 22:06:32 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <0a3864b522d890e0d1f16b45d9de3c70@strayalpha.com>
Date: Thu, 2 Aug 2018 22:06:32 +0200
Cc: Tom Herbert <tom@herbertland.com>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0967B124-4DE2-4E58-BDFE-39785EC27832@employees.org>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <0466770D-C8CA-49BB-AC10-5805CFDFB165@strayalpha.com> <6EDF0F79-C8F3-4F05-8442-FF55576ADDD0@employees.org> <alpine.DEB.2.20.1807271530280.14354@uplift.swm.pp.se> <CALx6S35LthDLRry7k-pF8KSoX4BXBA8kyArOpDUAcJMDCoLQpQ@mail.gmail.com> <alpine.DEB.2.20.1807280811540.14354@uplift.swm.pp.se> <8640DCF6-A525-4CF7-A89D-2DEDBF0FADC8@strayalpha.com> <FFF1C23B-7A24-46BC-929E-DD56C77D69A2@employees.org> <A248CA44-B568-4CB9-B450-067B1845AF9B@strayalpha.com> <CALx6S36w=5J0-=JQqrX0_PR7254V0HrhJct7oomPKdxSOSU43w@mail.gmail.com> <2872BF43-20AA-4179-9269-9C4FE6F5986B@strayalpha.com> <CALx6S35VidDr1uTGCHeb3Dcc0qF3O8Lz0vvV-XKPfbY057n6XA@mail.gmail.com> <cd34a1e8da6ff4bbf5b20875827d2a09@strayalpha.com> <CALx6S348jLsnHG3gp-mh9d4KJ1bROT3OcVz=XjwVgpv1aSsi_w@mail.gmail.com> <c271e9501b381c9be6ac1f3a0095a1d9@strayalpha.com> <CALx6S35DRCEjS5qaVkj2_FJzNumrkSfCZmoSJLueqqZs+pm9gw@mail.gmail.com> <240E40E2-81F9-4FAB-A271-825BD7AC6073@strayalpha.com> <96 EB5285-E0F6-43BB-A6CE-B087A4F8DF62@employees.org> <CALx6S36Ef3t7Axmx9hg994DHpVM=NdW-7ygf89E==gL4XKrkQg@mail.gmail.com> <5E21B3C1-0420-404C-9824-9B7E5A850BC5@employees.org> <CALx6S34qmKngi3hK_PVrJA1DMa5kfaLww3jfqRKN=up5v0Y0Ww@mail.gmail.com> <8D23C8B1-C2DA-4A8B-A2BE-8CCF6233B3A5@strayalpha.com> <D1D5EDCE-7C43-4CD8-947C-AA43CDB18892@employees.org> <1B04E207-08FA-400F-BBED-67379FEFD64E@strayalpha.com> <62804AFB-A3A9-45E5-8EEB-EF46CB37AB0D@employees.org> <ea11591585f8efb373ec6c273e9f750e@strayalpha.com> <5A8E1A6D-F9BD-4F11-B02E-0B23FA046DF7@employees.org> <0a3864b522d890e0d1f16b45d9de3c70@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/NWvDC961Y2EGmAYbYSarnl_Jgh4>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2018 20:06:45 -0000

Joe,


>>>>> I am not ignoring them; I'm claiming that they all have the same inherent deployment and implementation limitations.
>>>>> 
>>>>> Just because operators/vendors "want" to do otherwise does not make it possible.
>>>> 
>>>> There was IETF consensus behind those documents (A+P).
>>> 
>>> You mean the *experimental* RFCs that describe an approach that doesn't update RFC791? (i.e., RFC6364?) Or something else?
>> 
>> The protocol specifications of A+P are all standards track.
>> RFC7596, RFC7597, RFC7599.
>>  
> Thanks for the refs. Note that none of those update RFCs 791 or 1122, so if frag breaks them, then it's their error.

I wouldn’t be surprised if there were disagreements about that interpretation of “updates”.

> It also looks like (at first glance at least) these devices work only when there isn't multipath between the back and front side.

The A+P routers are stateless and do support multipath. Including traffic does not need to be symmetric.
That’s the main selling point for A+P, that you don’t need per flow state in the core of the network.

Cheers,
Ole