Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

Ole Troan <otroan@employees.org> Fri, 01 February 2019 08:42 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 9FEB91271FF for <int-area@ietfa.amsl.com>; Fri, 1 Feb 2019 00:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8uEJ7EvVIUQE for <int-area@ietfa.amsl.com>; Fri, 1 Feb 2019 00:42:11 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF4D12875B for <int-area@ietf.org>; Fri, 1 Feb 2019 00:42:11 -0800 (PST)
Received: from astfgl.hanazo.no (77.16.211.87.tmi.telenormobil.no [77.16.211.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id EB112FECC0B1; Fri, 1 Feb 2019 08:42:10 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id AC8B1DD6C16; Fri, 1 Feb 2019 09:42:07 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CALx6S35tKRUDuMQmpiA7dVJV7D9ijXAWD-exGe7-3xZT-k9XVw@mail.gmail.com>
Date: Fri, 01 Feb 2019 09:42:07 +0100
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Ron Bonica <rbonica@juniper.net>, int-area <int-area@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2479C8A9-6574-4A80-B156-BC64CB9130EF@employees.org>
References: <BYAPR05MB424584AA4D0D11D7D0098B81AE900@BYAPR05MB4245.namprd05.prod.outlook.com> <CALx6S35-F_8L+QCcwN6--3TrrRdE5OG3vUACTEH03AmKYerLSw@mail.gmail.com> <BYAPR05MB4245604C8E234D72F42E0D8CAE910@BYAPR05MB4245.namprd05.prod.outlook.com> <10861CAC-3650-4B69-A8B0-437C2A3494CA@strayalpha.com> <CALx6S35XMV+7uXoGatsFEg7Bh+ueuHGVDZrXa8o4cSQKdON7iA@mail.gmail.com> <eb0cd9a4bd898310122ea77e0fade3f9@strayalpha.com> <CALx6S3708uQN2cey8ZDWUKsRR0KUH_uEPk6JwUu4eY4h0Op6xA@mail.gmail.com> <75e840b19c2e439ab3ff13d7c105ce8f@boeing.com> <CALx6S35tKRUDuMQmpiA7dVJV7D9ijXAWD-exGe7-3xZT-k9XVw@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/s0WsZCLUhu_z7o3DP_fpB93sbH4>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 01 Feb 2019 08:42:14 -0000

Tom,

> It does seem that Cisco configuration manuals and marketing materials
> are the best source of information on virtual reassembly.
> 
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configuration/xe-3s/frre-xe-3s-book/virt-frag-reassembly.html
> is a little more interesting in that it provides a few more details.
> In particular the requirement that all fragments must traverse the
> same intermediate device is mentioned:
> 
> "The reassembly process requires all fragments within an IP datagram.
> If fragments within an IP datagram are sent to different devices due
> to load balancing VFR may fail and fragments may be dropped.”

I can’t tell if you are actually interested in how it works, or if you are trying to make a point.
Assuming the former, here is an implementation:
https://github.com/FDio/vpp/blob/master/src/plugins/map/ip4_map.c#L517

if first fragment in chain
  found = lookup 4 tuple in reassenbly cache
  if found
     forward buffered packets
  else
    create session state entry in reassembly cache
    forward packet
else
  found = lookup 4 tuple in reassembly cache
  if found
    forward packet
  else
    buffer packet

Ole