Re: [Detnet] draft-varga-detnet-ip-preof

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 26 July 2021 21:19 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3953A12CD for <detnet@ietfa.amsl.com>; Mon, 26 Jul 2021 14:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.885
X-Spam-Level:
X-Spam-Status: No, score=-11.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZELX6CHd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ct3N1TMQ
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 BvRzyCFxpoJA for <detnet@ietfa.amsl.com>; Mon, 26 Jul 2021 14:18:56 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46F33A12D4 for <detnet@ietf.org>; Mon, 26 Jul 2021 14:18:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34751; q=dns/txt; s=iport; t=1627334335; x=1628543935; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uPsGHYZ1MRsVg6KsBxnmiNkvpftJgIqHZChg6650KuQ=; b=ZELX6CHd5o3ak3iKazghX/TuCMHaBed0NGK5HYQAlJgTaNpOuuZfiDSx CBnWulQURSYFkZYXrKDOicTjxRqJrYN+860Nm8XZlSXT723O0OvglZG12 ke02iSlXPVVYQ3nYRKM3FlOYGyhJi/NdOwW6PWWSzyV/YlwCWRqsx3uJg o=;
IronPort-PHdr: =?us-ascii?q?A9a23=3ANvDxqx9Kb8RxZP9uWDnoyV9kXcBvk7T5IgBT7?= =?us-ascii?q?YAo2PpCcaWmqpLlOkGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW?= =?us-ascii?q?0oDjsMbzA0tHMDDDlf0f7bmaiUgF5FEU1lot3iwLUlSHpP4YFvf6n2/5DIfA?= =?us-ascii?q?FPxLw1wc+/0AYXVyc+w0rPaxg=3D=3D?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AQOdwdKnsGaAXMHzVnSQaP0yNze7pDfOOim?= =?us-ascii?q?dD5ihNYBxZY6Wkfp+V/cjzhCWbtN9OYh4dcIi7Sda9qXO1z+8T3WBjB8bdYO?= =?us-ascii?q?CGghroEGgG1+vfKlLbalbDH4JmpMJdmu1FeaHN5DtB/IbHCWuDYqwdKbC8mc?= =?us-ascii?q?jC74qzvhQdLz2CKZsQkjuRYTzrdHGeMTM2fabRY6Dsn/avyQDQHUg/X4CePD?= =?us-ascii?q?0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZcbxp/hZMZtUTVmQ3w4a?= =?us-ascii?q?uu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESvtu/oXvUlZ1SxhkFznAid0i?= =?us-ascii?q?dtrDAKmWZ4Ay1H0QKUQohym2q05+Cv6kd015ao8y7ovZKqm72IeNt9MbsauW?= =?us-ascii?q?qcGSGpt3bJe7pHof92NiuixulqJAKFkyLn69fSURZ20kKyvHo5iOYWy2dSSI?= =?us-ascii?q?0EddZq3MEiFW5uYdw99RjBmcoa+ShVfbbhzecTdUnfY2HSv2FpztDpVnMvHg?= =?us-ascii?q?2eSkxHvsCOyTBZkH1w0kNdnaUk7zg93YN4T4MB6/XPM6xumr0LRsgKbbhlDO?= =?us-ascii?q?NERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfkIzfDvfIZNwIo5mZzHXl8dvW?= =?us-ascii?q?kue1j2AcnLx5FP+gClehT0Yd0s8LAW23FdgMyzeFPGC1z3dLkeqbrXnxxEOL?= =?us-ascii?q?yoZx+aAuMjP8Pe?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeCQB+Jf9g/5JdJa1aHgEBCxIMgg4?= =?us-ascii?q?LgSMwUQd3WjcxhEeDSAOFOYhgA4pYj1mBLoElA1QLAQEBDQEBKgEKDAQBAYF?= =?us-ascii?q?CAYJQRQIXgmYCJTYHDgIEAQEBEgEBBQEBAQIBBgR7E4VoDYZCAQEBBAEBEBE?= =?us-ascii?q?EBhMBASwLAQsEAgEIEQEDAQEhBwMCAgIfBgsUAwYIAQEEDgUbB4JPAYF+VwM?= =?us-ascii?q?vAQ6cUgGBOgKKH3p/M4EBggcBAQYEBIE6Ag5BRoJ3DQuCNAMGgTqCfIJxU0g?= =?us-ascii?q?BAYEYhUsHIByBSUSBFScMEIJiPoIgQgEBAgGBZAcfCQKCXzaCLoMXblECRhU?= =?us-ascii?q?LMi0IDQUekisHAoM5iDqNOpE6XAqDJoo3jiiFYQUmg2OLXoY/kGOiPoM0kB8?= =?us-ascii?q?EgXqDCQIEAgQFAg4BAQaBZwctgVlwFTsqAYI+UBkOjh+DcYUUhUpzAgEBNAI?= =?us-ascii?q?GAQoBAQMJiyABAQ?=
X-IronPort-AV: E=Sophos;i="5.84,272,1620691200"; d="scan'208,217";a="905291764"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jul 2021 21:18:54 +0000
Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 16QLIrP9025031 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 26 Jul 2021 21:18:54 GMT
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 26 Jul 2021 16:18:21 -0500
Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 26 Jul 2021 16:18:21 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 26 Jul 2021 16:18:20 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OoxHo07QM41lcMRAcSBfbJxNiJzJ9Hp7EzOlafK31yDLPvpFsJqEyz5yUFl0nWMvR+nl3Rw06IFgKxKxtORpdsK/zSC7iabq4d+yp4Qr+0htn3NMLdt0F5elr2LDvknI01iillEW46++JzkZjVBvCPN27llpzFzBtFYatKlQr+4aHX99/tVPTCr/B/AjZnCuad9eULoRd6+rWhFATMOf7ryZ/i4V6WQgUdYbRqVeB3lJwxdglEuTtQoHExOBKJmIyKoCbciAS+cn/ozXAgMEMtmK1h22/DTpQF1pb3fIe+5Opb02iHzX/nNNdU1G1ELM4Nhf8cj1FLjbd2maSW0EUA==
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=uPsGHYZ1MRsVg6KsBxnmiNkvpftJgIqHZChg6650KuQ=; b=ZRCktpxZqTToJVjb+t03i5kbrRrdrrxbKOQ7h0j5Mc6aq9Yc+Ry0MKoHHspCuBY6lNEw4bETXE7AbIUBYoGmwBsYiyBNkLQIW9xoHtzKZusJYvup6PJ2EI435X4jCRkcF0te3+vpT78UFnzJM8XvbV72IGBn2IHZHe5IIe+708oaXGCJj5Qj3K96Dj/0tkOodbCnuvc/wE7UDB+KQFQXr6Z69fppD16dn2ZCFaDctc1wmAhHpS5rZE1p7+PTKS1HMOWbjAPoXBRgyzWybpMJ9kyguJ+JUPO6Yjf6T0hkE7NEbxhBz3dG0O7Z3AhA5ynrHgmnXDPwosMotR7GpBFDfQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uPsGHYZ1MRsVg6KsBxnmiNkvpftJgIqHZChg6650KuQ=; b=ct3N1TMQ2IG038eTezmvEGJrSGLCXnhNg7Qw6iHv/V5prbrA9psA6K0Djo9O1VQkIPgJhrqFNtzBAxhuu1XYTVIVM1CmLzOyUIGoB1VB5XwpPZTje/s/2C7BJ7rRqLCs/5vcrXleLnKV2o/uKaDWyoSgRoG4bAzXjGqhqR1aSyw=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB5089.namprd11.prod.outlook.com (2603:10b6:303:9b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.26; Mon, 26 Jul 2021 21:18:19 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1c75:fcc9:2c53:3af6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1c75:fcc9:2c53:3af6%7]) with mapi id 15.20.4352.031; Mon, 26 Jul 2021 21:18:19 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= <balazs.a.varga=40ericsson.com@dmarc.ietf.org>
CC: "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [Detnet] draft-varga-detnet-ip-preof
Thread-Index: AdeCJhL5qclO3ipmQnOhnkjJnCiKCAAE+ubAAAYMvuAAA3HbcAAA8i7v
Date: Mon, 26 Jul 2021 21:18:19 +0000
Message-ID: <6E1BB2CC-FDCE-4F97-9036-894B7C30B904@cisco.com>
References: <CO1PR11MB4881E860FF54BFB6CF04BF39D8E89@CO1PR11MB4881.namprd11.prod.outlook.com> <AM0PR07MB534784B537193F4F88241045ACE89@AM0PR07MB5347.eurprd07.prod.outlook.com> <AS8PR07MB8298836F25EE12742C278B44F2E89@AS8PR07MB8298.eurprd07.prod.outlook.com>, <AM0PR07MB53475FF5EC7C92D8285A27F0ACE89@AM0PR07MB5347.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB53475FF5EC7C92D8285A27F0ACE89@AM0PR07MB5347.eurprd07.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ed2e292b-6411-4231-28db-08d9507ae45e
x-ms-traffictypediagnostic: CO1PR11MB5089:
x-microsoft-antispam-prvs: <CO1PR11MB508964138791E6A7E1B67865D8E89@CO1PR11MB5089.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gZRh2FJ7HZiW8GPKPgVO4sHWFX/DhH5qNXPkJ6NkocIYYPXMELCuRx/jOQMZLK8YdKnF5V4/vAQECUoGIFG0PLFth4mUGEIeickmhtjXK0Cev6uT7CctUQ/qDcVnSaJtuOujr5INOCoUfsKO3ScJgRzdC7DAhdPMux+3APJ0MZUMQDGrcvYldjEoyAw5sGis5Zm57gXcOPSRck6lRHbhQN0aI2o0ZuqrvLjd2kNGy/jV7rA7dA2bZ8FHWQ3PYdk5Qb102BNSzZDUqJY+/R8DdGLtGx9C4vNq3QFam5LonbM6gQedQUzlYbnYUp9BntYLYM5FmDigPLHQj8TCF1ogKqcxeDQngSrbTPfqmdv5ZpGx6QVVFm8fPQIw4cwrJYIHa39X0uWOWpkQm5VFYDL7asd2CksSHoBE+dUmo6/WZKZygTUfjswOs1anVJiPKLxyabaoBTOoFSchvgEVDFFipS3RaEFfieCwHkTqq0v9y8n4ch58H4nAAguJ/UKSpaHoGEB9cIk6jlnnIUdBWKvpWzDTWRUQJ5+qCX3zPW8QQLQi7lfBegoK46vtJdAh61oIaXsSvphgQWIFhr0IQa1GZT8cYspJjT+4ZCjQHqlAVJTf6W7ks0tUZn2E++FAoESKUVhM/z3Vy3fN9ttbLx+O2cvYu3Wh8acoTjZF2XdKzeVVnMWeeLYy0fwHF07pwWrORLIN8wpGnaWEOncIU0bVwm4B1RAFN3KM8Q9QHCswbr8HDL0biGuBQJcvwTv+529sycc7xG6wmXrbnWIC9qucNT68t6XmMLu1b+vxuehupTeMdzQXgVICl4TSB/I5ytYHuxBGsmC9nBOsyGppk/0tuOwF/wYIBx6N7qbbMRYdUYqctdzPDD3kirAzT/RC6+Xw
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(396003)(366004)(39860400002)(33656002)(83380400001)(66476007)(66946007)(91956017)(76116006)(122000001)(38100700002)(64756008)(66556008)(2906002)(66446008)(166002)(6512007)(71200400001)(66574015)(478600001)(966005)(5660300002)(8936002)(86362001)(8676002)(186003)(53546011)(6506007)(6486002)(316002)(2616005)(36756003)(4326008)(45980500001)(38070700004)(244885003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ODJKdXVtclJkZUNvNStiQ0NHU1BONDhCSW5yZ0M0akxoakoxaWN0dDlEdVYy?= =?utf-8?B?elNCeDN6SnNDckRFbzBmWW9lcVlmZ21idDd2b3RtMHhWQUxUODFLTUZnOEJZ?= =?utf-8?B?ZFJmcTVYUmVYaW9jU1NSOHJsczdYSzBWYlM3MmxUODZDdEJ2dU4wMmFVbXdn?= =?utf-8?B?RFRMeEYwNzlzcW1uTkJRNjJvMitRaVEyR05FdWVPenNOenhrcHlRZEJjOWpD?= =?utf-8?B?a1pVeTlxUU5jRHZHM2wzSTBKUzZ4eWFCTUlNZkJSS0J4cTJaVU9Ua3RQdXJG?= =?utf-8?B?RUtRT29zWCtCYmY0enVtVVo0aERtL3YxK1Btb2R4elhKSk5MOTZ0RlJDdEdD?= =?utf-8?B?UTBJN2ZQU2pCQmIyb2JnWVV3S2ovaG1SRjlGaTYva2g5b3AvNUdJZk5hL05k?= =?utf-8?B?UkN6eklhdlBVUVBaU3RvUHljdUdoV0pBN0liSFdFQXZjdVp1Y25mQVc1enls?= =?utf-8?B?RjYwWUJhRWNCTmJjUlVnSU02WnFLMHdtSzJGSyt4a3FGaTZWM1lqdFdFU1VX?= =?utf-8?B?YndnUmVXTEF1ZzlNL25XQSswWGxxQ1JRTkZzNVYyQWVPRURBYXAxZi90Nkxk?= =?utf-8?B?RXhTLzA1WG0zSGYzQ3BQSlh0WHQ4ckgwbHg0K2NjWjFxZmNYbkZNWklaL2Vu?= =?utf-8?B?VkpQWVA2MkV4T2RibmRzTUcxV3FOSEhOWGVqMUtjbXk4VWJ3WHZpOWxIclY0?= =?utf-8?B?cU1HOW1ORUNZZW1PZU4zbjNLcHJmT051UE5mNlJXUXY1WG5hR0duNlAzM0ls?= =?utf-8?B?M0JRdmhIZEhnR2hoWWNsTUZOQU9BQjE0d3FFYTJZNHdQNXdUUk9DOUIxVU8z?= =?utf-8?B?c1owdk12NHpLWGI1Y2RrL0FhSmFoaW0zRFZGa3dEazRkem9CeXpxUXExTVlK?= =?utf-8?B?UUNiS0MxdElYdVZ0Wkh0N25jY1krRlFic3RSb2s5QkRmMzNSYzJkeUh6Z2ZX?= =?utf-8?B?QlM0eWN6elk0bVNTRG03ME04TmlOeG03U2ZHQ09ndzZUcmhxdFhEYkkydGlI?= =?utf-8?B?bklPU3JSbDhxb01LdWhsd1ZnR1J4S3VvMVJIUk56TXd6Rm8vWEtnVnlJS1dh?= =?utf-8?B?Z3F1dzdLbm1SeUlTZ2thNmJQRElnd29yYkI0czJDbGRXZHRrTTNXSUNwa2FK?= =?utf-8?B?VVpPbW5BYkU3UzhOSU9sY0t4OS90KzJJTEV1M0tKNnMzWTZaOWtIYjNYR2VG?= =?utf-8?B?RkpsS2cyRTZuQ0JNSEpTRjZUSEwwN1I0RlpkeG9WZUR0clJLeEZRbFRkQzE2?= =?utf-8?B?eVBpQ1M5Q3JEeFEzSHhKa2dzNngrV2VVNjh6d2pEV05iTFB5c2hpQWZWVm5N?= =?utf-8?B?UitzYWFJSytYaDRMVXRIZWh6MVBmSmNnVmh1Nlo2cEFnV25TS2hWYTFkTFlX?= =?utf-8?B?bEk4Tmx6UGNYYnBPNDIwR0h5YTYxSjJ6bFZlVldrQ2phNHRhRENxbWZoQlRW?= =?utf-8?B?akRZejV2b2c2STBGaEdQRVlOTExielFPVFF2ZHNDSnBHYU82bjhCTlYwSHZX?= =?utf-8?B?TDV5T0FFbW9tc0twaHhOTXY5blhGMmxRamVRSmkycFRDdFhnOFpocHpuSkRi?= =?utf-8?B?MnJKcmtQZEJVUjh0U2hmMEM0SEwxSWM3MmYrSVZ3Z1pweVJ5T0pON1Z6Ympx?= =?utf-8?B?em4yRkZZOUVvMzV4V2RvQ0Jtck94QVhTOWNDcmxaWG1Ncm1HN2d4MzJQMEpT?= =?utf-8?B?M0dSSm5zS3ZiQ2tXRytRQ3BWK0o4SUpDSDBjTzNjcFZkQlFWUW1JWVZRa08z?= =?utf-8?B?cHlsdkZhMWR2dFJZQmU0Y3dvV0FXZHhCZlA0cWNvSHZwUE1LRGpqaXg5V2tE?= =?utf-8?B?ZUpvYS9PR0VseUJZRkVmcDZ1bkExNGpvU0EyRXU2MTcvZmhIMjN6djJVNE0x?= =?utf-8?Q?yAlO8lrc+Uipo?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_6E1BB2CCFDCE4F979036894B7C30B904ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ed2e292b-6411-4231-28db-08d9507ae45e
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2021 21:18:19.5252 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2ogCAyor+sHMqea5AVVTvkplIVZA6ETZAhK1dSrhpR+NdZhogMXDgZCqpSKaL4rkxOIe0thYwknpfGP00tSErA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5089
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/wOSsqcCFKaxPr7_p4bN5nN1fSvo>
Subject: Re: [Detnet] draft-varga-detnet-ip-preof
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jul 2021 21:19:03 -0000

Hello Bala’zs

Many thanks for the clarification; I expected that the aggregation label would signal a common path but from your response it seems the draft still relies on the flow to find the path, based on the 5/6 tuple, correct ?

My bottom line stands though. Aggregation and PREOF may happen inside the network. And it means encapsulation. Going all the way to UDP will make the header to insert and read bigger.

 I understand now that you place only service layer information in there, but that still needs to happen at wire speed, and bigger headers can be counter productive for DetNet tput and latency, and be more complicated to implement in hardware.

Do I miss anything ?

Pascal

Le 26 juil. 2021 à 23:00, Balázs Varga A <balazs.a.varga=40ericsson.com@dmarc.ietf.org> a écrit :



Hi Pascal,

Many thanks for the clarification questions.

Please see my comments inline.

Cheers

Bala'zs





-----Original Message-----
From: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Sent: Monday, July 26, 2021 4:00 PM
To: Janos Farkas <Janos.Farkas@ericsson.com<mailto:Janos.Farkas@ericsson.com>>; Balázs Varga A <balazs.a.varga@ericsson.com<mailto:balazs.a.varga@ericsson.com>>; agmalis@gmail.com<mailto:agmalis@gmail.com>
Cc: detnet@ietf.org<mailto:detnet@ietf.org>
Subject: draft-varga-detnet-ip-preof



Hello Balázs, János, and Andy:



In prep for next Friday meeting I went through https://datatracker.ietf.org/doc/html/draft-varga-detnet-ip-preof-00. I have a few questions that might be too much for the mike, and considering the short time we have, I thought we should start here.



- At first glance the draft seems to be placing the DetNet MPLS dataplane within UDP. If that is the intention, what are the benefits vs. using RFC 7510?

<BV> No, this draft is not about putting the MPLS data plane into UDP.

This draft is about how to provide PREOF for the DetNet IP data plane in a simple way, with no new header or data plane definition; but leveraging existing ones. That’s why it is informational.

That is, this draft leverages RFC 9025, which leverages RFC 7510. It is applicable both to IPv4 and IPv6.

Key point in this draft is that DetNet PW (S-Label + d-CW) is placed in UDP. It is very important that there is *NO* label switching along the path.



- Some of the labels in there are needed at every hop to select one or more next hop(s) along the DetNet path. Can it be a problem to find that information deep inside the packet?

<BV> No, the DetNet PW information is used only at relay nodes (as per rfc8655 those includes DetNet service sub-layer). Intermediate nodes (transit nodes) do not need service sub-layer specific information, so they do not need find anything “deep inside the packet”.



- There can be variations of the label stack, e.g., fig 3 vs fig 4. Are the labels self-describing? Else, how does the forwarding node know what shape of stack to expect?

<BV> As the DetNet PW information is used only by relay nodes, they know by configuration of the service sub-layer (e.g., PREOF) how to process the packet. From service sub-layer perspective it is the same concept used in rfc8964.



- I'm concerned about the aggregation scenario. Contrary to MPLS, an IPv6 intermediate node is not allowed to insert headers, in particular not after the UDP header. So it seems that the aggregation proposed is always done at the end points. Is that correct?

<BV> Aggregation just works fine. Any relay node can perform aggregation as UDP tunnels are span between relay nodes.



Please consider the following picture from RFC 8655:



   DetNet                                                     DetNet

   End System                                                 End System

      _                                                             _

     / \     +----DetNet-UNI (U)                                   / \

    /App\    |                                                    /App\

   /-----\   |                                                   /-----\

   | NIC |   v         ________                                  | NIC |

   +--+--+   _____    /        \             DetNet-UNI (U) --+  +--+--+

      |     /     \__/          \                             |     |

      |    / +----+    +----+    \_____                       |     |

      |   /  |    |    |    |          \_______               |     |

      +------U PE +----+ P  +----+             \          _   v     |

          |  |    |    |    |    |              |     ___/ \        |

          |  +--+-+    +----+    |       +----+ |    /      \_      |

          \     |                |       |    | |   /         \     |

           \    |   +----+    +--+-+  +--+PE  |------         U-----+

            \   |   |    |    |    |  |  |    | |   \_      _/

             \  +---+ P  +----+ P  +--+  +----+ |     \____/

              \___  |    |    |    |           /

                  \ +----+__  +----+     DetNet-1    DetNet-2

      |            \_____/  \___________/                           |

      |                                                             |

      |      |     End-to-End Service         |     |         |     |

      <------------------------------------------------------------->

      |      |     DetNet Service             |     |         |     |

      |      <------------------------------------------------>     |

      |      |                                |     |         |     |



          (RFC 8655) Figure 5: DetNet Service Reference Model (Multidomain)



You'll note that the DetNet architecture allows for endpoints that are not service-aware, in which case the service layer information is logically owned by the PEs. A PE should be able to add / remove stuff that is relevant either within its domain (e.g., PREOF using SRv6 with Xuesong's SPRING draft) and / or within the DetNet Service Domain (across domains 1 and 2 above), e.g., redundancy information, excluding the End Systems which may encrypt their payload and may not provide anything usable for redundancy anyway.



As a specific example, the aggregation should be feasible between DetNet-1 egress PE and Detnet-2 ingress PE. In IPv6 this means encapsulation, and it makes sense to minimize the incremental size. UDP in UDP seems a lot doesn't it?



My bottom line is that if we want intermediate nodes to add and remove stuff, it has to be thought in terms of matching encapsulation and decapsulation. IPv6 has EHs that are designed to fit in such encapsulation, possibly together, like an RH for replication and a HbH for path and redundancy information.



What do you think?

<BV> Again, the DetNet PW information is used only at relay nodes (doing service sub-layer). Intermediate nodes (transit nodes) do not need service sub-layer specific information and do not “add and remove stuff”. Aggregation and the DetNet service reference model just works fine with this solution, which just (re)uses existing DetNet data plane.



Pascal



_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet