Re: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-route-09: (with COMMENT) - extract: same flow

Ruediger.Geib@telekom.de Mon, 10 August 2020 07:21 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 EB4823A1444; Mon, 10 Aug 2020 00:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 wh0ePaGot29a; Mon, 10 Aug 2020 00:21:52 -0700 (PDT)
Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E76A3A142B; Mon, 10 Aug 2020 00:21:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1597044112; x=1628580112; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=xKTW1xHawxrC2GHvSQzYW07ukFQ5c6uHc71ZY2d86vs=; b=EOQ99h6J/NsUbllJDcgxtX3XkJlm+OID42rQ0YLIzIEh9uC+8wF9Bu6H jq4U8RvERZnixM0JdtM8QiyqDsy0m9dY21dBMLOXH+nG6EaPq2O4rekPz lIy3ZHO2h8JdU5pTE1w9Jb3Q4/9nJ1aJdjoiB8poLam8NzNEmZuUzH9Nn DFvssLEinQNYJP9kdsHQmaMA+Z9odVx1NdPlVxUgpzasZq/uq7ecl46R0 6Dgs9hPj0pBQjR7R0m6SOTJNJ56HKHWve9G4RPlBEkGU7FkOGeJCMYGFt CbtrFVGFgr/KnLIpctJ0rWNCbNKnv+VWJD4iQntNqaslKBregUawG201z Q==;
IronPort-SDR: yjVRjepPsUx13eP+jSOI+5hafKAsLx0vq/RP2Amz2b4K2SV9ifCVigvygrmdq+yUbeXer8ODVQ x8ZpABufYwRg==
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 10 Aug 2020 09:21:47 +0200
IronPort-SDR: mutIeUkR4Hhe5TaDh3Zz+P6I8sWvBxvDN15BzYp4VvuyF778joEzKhMexBqe99iq/fw8JP+TqS ytEgLWdCvLspQWB34/phQzlGiPVgusY3g=
X-IronPort-AV: E=Sophos;i="5.75,456,1589234400"; d="scan'208";a="166527825"
X-MGA-submission: MDEd7Llg8YHPBHohv+PxLG+oDdxEVsi93G5mdB69fxKkW9xKKGEAnlIfhQrczxqau3RK1b5rWyYHFGZm0fXMXFh6GaKla774uL1EQhAYmjfy8zDlq0gwUaUPLL8ux+KhSXNldcOxeZpP6qLg+CQdLdiFKsIqkoofbrUpzzaILGgg3w==
Received: from he105709.emea1.cds.t-internal.com ([10.169.118.41]) by QDEC97.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 10 Aug 2020 09:21:47 +0200
Received: from HE105709.EMEA1.cds.t-internal.com (10.169.118.41) by HE105709.emea1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 10 Aug 2020 09:21:46 +0200
Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE105709.EMEA1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 10 Aug 2020 09:21:46 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.22) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 10 Aug 2020 09:21:44 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V9TltA3L6WSF5TWlgOcFiH1Q830rL77XE5Aui2eq5CMkoZirI+jQx4mKUWRuzYT2OVVsHH/XAgsrDQG/0yAQLwbeMFAplEdq3QDHM93Bwp91FB/GTfHv2gwrKorchLGlKR32YgYoAGawN4Ambi7kevfga1+PK3pblDKuKaNq8qchYw3Acy2EA/XjKDGPqStm6qsvRsWYHPrQYqGh02pehUJAm3aJMxkdowIjyW+oUnbzgYD+oO8vP6Ax1D8k/kLKi3eceDeVpLLhtNKFJWqB81p6P35+wiyLK57Fg93OIU4wrx+2E6iAbdae/r4PnWY8M3Y28Szh6hZ/SA12LEB7cw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xKTW1xHawxrC2GHvSQzYW07ukFQ5c6uHc71ZY2d86vs=; b=QKw80nmEy2GBrqBIPBkYtb0cJw0ZMuvI41udjbAKBAaYpiodse+zhzRgwDnc9JjNOGE2hKyn2f/RpJrw9F1tlwsR6cLno/mEIvpYu8PFKxwk7vY6bmGxyvk8x277Oii1lBb0RHU7FYFI5aSMc6nXL8o+vLDrWv/qgcr3kWR89TrX8PifsgF6lvLLkFu3oDi/2k9SibqAamrD4jGygfNK/eRpDREF+P5N+n0ykhzXBvvVU0TD26eBJgQFJmvJ6yfc2clmp3CPMiKhLBzv1SQf/gYNQzWZedXWXQsSyQTEbH51nzClg4G/aYkQX/uuNpaUpKeD0NxfcgwRgliDk/K4Rg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FRAPR01MB0546.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c010:d::16) by FRAPR01MB1059.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c010:8::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.11; Mon, 10 Aug 2020 07:21:46 +0000
Received: from FRAPR01MB0546.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d0b5:751f:955b:45ac]) by FRAPR01MB0546.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d0b5:751f:955b:45ac%7]) with mapi id 15.20.3283.014; Mon, 10 Aug 2020 07:21:45 +0000
From: Ruediger.Geib@telekom.de
To: acm@research.att.com, kaduk@mit.edu
CC: draft-ietf-ippm-route@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, ietf@trammell.ch, iesg@ietf.org
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-ippm-route-09: (with COMMENT) - extract: same flow
Thread-Index: AdZu3wiSLwbeDihgToSB2TT/H3C6xA==
Date: Mon, 10 Aug 2020 07:21:45 +0000
Message-ID: <FRAPR01MB05466F4C5F54885227134DF49C440@FRAPR01MB0546.DEUPRD01.PROD.OUTLOOK.DE>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: research.att.com; dkim=none (message not signed) header.d=none;research.att.com; dmarc=none action=none header.from=telekom.de;
x-originating-ip: [164.19.3.245]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 06467735-619a-4e8c-8f17-08d83cfe09fe
x-ms-traffictypediagnostic: FRAPR01MB1059:
x-microsoft-antispam-prvs: <FRAPR01MB1059CF5C9AED43D0EBCCCC659C440@FRAPR01MB1059.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: x6CQh7E5Jfm3dLevhzNTKd51wU8TZOolfCsQh4geSgsXhiwS45f5sCfc7HT1S5t/YykK573onkT7WVlemZU/u2PjM8Fc/Ut/iDJqxjouTSeaU+Oe4zeb96WesppeSqhy3E0pyx99cTTseNby0v2Es1l8/eJS291EgY0cOI7gLrlA/TiC4GWAO+Za4J7HP3Ylmz9Z6H8soU0j38LYuF2nliqLX0oZiNQOlA2roTZmmvwCNqfH/d6/rRKnZJP0k+VfVWxSpH1DrxzUKfEblrMli0NRSADzZgTnQd0edWZBA/x0owNkv1/O6G2PXcWfks82DdZebnW6ECjqslY4XGr1BO5U1FsD7XENdfrebt62b/375IaDe3wObOOO6nfSRh/+
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FRAPR01MB0546.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE; SFS:(39860400002)(136003)(396003)(376002)(346002)(366004)(66446008)(85202003)(66946007)(26005)(9686003)(64756008)(66556008)(66476007)(33656002)(66574015)(85182001)(71200400001)(478600001)(5660300002)(186003)(86362001)(4326008)(8676002)(110136005)(316002)(7696005)(83380400001)(54906003)(55016002)(2906002)(8936002)(4743002)(76116006)(777600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: upn4Emz550v7ir826vsPQQPzXDTdT+7FFo074gQsOydYpB7l6JZkMVEqk7QN49pqBOw67pbujTLmPUnYxUA6bqaljepAH3K1DnnHAdJR3uUxpLIVWygwSTIYvPlBL3TTE/33FFOGfVBOPox4faZGbUShRri0p7Dsv4G62lIpeTrOo4rRCgxs+Bed1En5I31m0Wnh5RxfA7PClVAbmv4fGy2h3mOf+bo2OsFyI0UHrJzu9+MzL+4PLpv0DpZpx2XMudtsusr6sj8GKi76J6xwIKbvACILB+tIe9lHPPuZTki6DfoHdg8SqwuV3eCX7ms0b2NnkEFX4pCJxd63BMeG1C8/4oEh1LshvdYGtAUyPYJaWdfwEDne4jV9DkfkPBAkm0QwvplVGMEr/kr2Z/ckTO9cyZ/y+DQSJVRTedDxVj/G+D/JKKOvzGrBMcors+YxefuTnXAKIKLYAAmTRaGoXrcGuaScon1EbNAgiP9o6lqwDg+1u+UzpEf8q1XAIvj+JgHgiua/vuV8y0j9jwjmc/+ieK7HznoUcn7KczwXJyyYlWmiAKmdT0iPnPni2WsP20zf4lAfEwf8BANJHiajF/cD6xbYoCzvcA/Q1Rv+HT6BRUlDMY1tE/ivEQPXWjOLQ1BiKcGnr2zTKdQo7ds5Bw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: FRAPR01MB0546.DEUPRD01.PROD.OUTLOOK.DE
X-MS-Exchange-CrossTenant-Network-Message-Id: 06467735-619a-4e8c-8f17-08d83cfe09fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2020 07:21:45.9153 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mlJFJMqzGP+Gx01VBlxARhAt6Nh2kUOTV2IST9doYYz/lQcv7OVT0OSQ3sUInY46VOAR33zW+VJv99t6nzYshrYvehjjGxvTTtNoETJuvLQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB1059
X-TM-SNTS-SMTP: 54B94B855952D2B111727BB98C17CFF30145E7E2526EE6ADA3E7F14722DD18642000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/6Wl8-hs2skUrzOw9tz0MpEJeYZY>
Subject: Re: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-route-09: (with COMMENT) - extract: same flow
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: Mon, 10 Aug 2020 07:21:55 -0000

Al, Ben,

thanks for extensive reading and discussion and for proposed resolutions. Al asked for what others say in one point:

> 
>    o  TCP case: For IPv4, the fields Src, Dst, port-Src, port_Dst,
>       sequence number, and Diffserv Field SHOULD be the same.  For IPv6,
>       the field FlowLabel, Src and Dst SHOULD be the same.
> 
> Are we happy to pair "to maintain the same flow" (previous paragraph)
> with "SHOULD be the same" (here, and subsequent bullet points)?
[acm] 
There are ways to conduct valid measurements with SHOULD, IMO, but I see how MUST results in simplification.  Let's see what others say about this; no change proposed yet.

[RG] The set of packet information to base a load-sharing decision might be defined differently by a chain of nodes on an end-to-end path. Different operators may have different preferences and a Layer 4 device my base its decisions on other parameters than a core-router. The other way around: would a MUST kind of imply that we were able to offer a reference which of the mentioned fields specify a flow (we can not and we should not, I think)? Leaving it as a recommendation, and yes, a serious one, is better, I think. Thought the other way around: I some cases, there may be limited flexibility in flow definitions at some nodes along a path, and it may be useful.

Regards,

Ruediger