Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 02 April 2019 07:33 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958CF12021B; Tue, 2 Apr 2019 00:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 kD6AFZ4bj6YV; Tue, 2 Apr 2019 00:33:16 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 BE45112027C; Tue, 2 Apr 2019 00:33:15 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1DC67B1; Tue, 2 Apr 2019 09:33:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1554190392; bh=XjlET91oK+ILIdDQ+ilC6aJuDE11QftMcBcWACJx+cg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=l57YAf2nbRdeWlNlfqzgqXTA0g4pq1etFGqZO4WBivKos7sA0HqrqZGu1l5RtEtvt 8jqXP4zcwHV/uhQK0MsKtr/+9i/jUS666ErsFDaKE52ipsTSjG94hcianobTD+lmJt m7ngohYLqzIuReETqu6OA+5uDEhaNfQtVNbX55f0=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 19E6FB0; Tue, 2 Apr 2019 09:33:12 +0200 (CEST)
Date: Tue, 02 Apr 2019 09:33:12 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Tom Herbert <tom@herbertland.com>
cc: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, "C. M. Heard" <heard@pobox.com>, 6man WG <ipv6@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
In-Reply-To: <CALx6S364AzeZL0+AiPWUj5q_mu+9JAa2taGebos83X6X9Xtz5w@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1904020930120.3490@uplift.swm.pp.se>
References: <CACL_3VGxyn-PYosFsKPVdd8C=P5AbE6HD1zrimHKuh2MPkhnuQ@mail.gmail.com> <CAO42Z2wGMzc_RT=eWTx9Ve-5reS0nCWiteGOuE16=MB4Fg8mkg@mail.gmail.com> <f50040ab52d04867b9a5cefa1c3131c3@XCH-RCD-008.cisco.com> <CAO42Z2zgguekybwVuCh8Az3mK8gHp292BYnWYhJq-8KEyfKzOA@mail.gmail.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <CAO42Z2y5TS1+8YxNsr=BKz5v8-ZPTiO-M7CU2k6FzNqVZoU4VA@mail.gmail.com> <CY4PR11MB1335960AD9BF9A4B990F7E10DA4A0@CY4PR11MB1335.namprd11.prod.outlook.com> <CAO42Z2xqq=uksNQPxvF_CRSxf1V_MADbFurzW4hqQW0v478cyw@mail.gmail.com> <DM6PR11MB36254EAC97ACF07F5BAD43CADA5F0@DM6PR11MB3625.namprd11.prod.outlook.com> <DM6PR11MB362528DB0EADA21493CC49A3DA590@DM6PR11MB3625.namprd11.prod.outlook.com> <alpine.DEB.2.20.1904011139550.3490@uplift.swm.pp.se> <BN8PR11MB36181C47785968D8FCA2DED9DA550@BN8PR11MB3618.namprd11.prod.outlook.com> <alpine.DEB.2.20.1904020744260.3490@uplift.swm.pp.se> <CALx6S364AzeZL0+AiPWUj5q_mu+9JAa2taGebos83X6X9Xtz5w@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/WHI7EYDQl6NDr5fvax_F4giKyZM>
Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 07:33:19 -0000

On Tue, 2 Apr 2019, Tom Herbert wrote:

> This is solved with proper use of the IPv6 flow label for ECMP instead 
> of devices continuing to try to find 5 tuples buried deep within 
> packets. DPI is only going to become harder as more headers and 
> functionality are added (e.g. segment routing header will be another 
> problem, deep headers will exceed parsing buffers, and it's impossible 
> to find the 5 tuple for a fragment and still be stateless). Since IOAM 
> is used in a limited domain, the requirement should be that all routers 
> in the domain support ECMP routing using flow label (note that is a less 
> stringent requirement than all routers having to support IOAM).

>From what I have seen so far, most devices if they support flow label for 
ECMP, can/will use the flow label in *addition* to 5-tuple.

For the requirement of IOAM to not have separate ECMP characteristics then 
the entire IOAM domain will have to be configured to use 2-tuple + flow 
label?

Do we have data on how much end systems use flow labels nowadays? If this 
is low, do we have data from OS vendors that they're considering 
increasing the use of flow labels?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se