Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm
"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Tue, 28 March 2023 08:55 UTC
Return-Path: <rgandhi@cisco.com>
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 9825FC151B18 for <ippm@ietfa.amsl.com>; Tue, 28 Mar 2023 01:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.888
X-Spam-Level:
X-Spam-Status: No, score=-11.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, 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_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b="S/MVaprm"; dkim=pass (1024-bit key) header.d=cisco.com header.b="f9TuCtbe"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWH83I71Ctw4 for <ippm@ietfa.amsl.com>; Tue, 28 Mar 2023 01:55:46 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2516C151B12 for <ippm@ietf.org>; Tue, 28 Mar 2023 01:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=122896; q=dns/txt; s=iport; t=1679993745; x=1681203345; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iLgsHkK7sP4rpae0jZN8ddObTy2gC1WsnRw/hMLfs/0=; b=S/MVaprmutEg91A4RUQRn7mw1oAnDixmQPSvmRV5QkCFGxZJ9C7AL6GX AISsoUOu2CSiJViYY/4Dq5rL099REi9Ou8rTs7f0Y3AFCdTFH5+3kfCjI Bk/I/R+Dctvny8kDOXIxJG2oQrMwMQY5VsjfS4ucLS3AAG9gxWLf8NY/Y o=;
X-IPAS-Result: A0ABAACCqiJkmIENJK1QChkBAQEBAQEBAQEBAQEBAQEBAQESAQEBAQEBAQEBAQEBgXsEAQEBAQELAYEqMVJzAlk7RoRSg0wDhFBfiDEDi0iIBYNxgTmBTC2BOIEsFIERA1EFBwgBAQENAQEuAQoLBAEBhQUCFoUiAiU0CQ4BAgQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEeGQUOECeFaA2GVQEBAQEDAQEMBAgDBh0BASMGAwQHAQ8CAQYCEAEDAQIhAQYDAgICHwYLFAkIAgQOBQgaglwBghUTAzEDAQ8GPpJTjzwBgT8Cih96gTKBAYIIAQEGBASBPAIQQZo+DYJGAwaBQQGHQwR2XQEBgVKBf4IUgjMnG4FJRIEVQ4FmgQE+giBCAQEBAQEXgQwFAQcFBgEHCxEeDQkCgyA5gi6JfoQdiyUKgTRzgSAOgT2BBAIJAhFrgRIIa4F8QAINZAsOcYFKAoI+BzYDRB1AAws7Oj81FCAFBFWBGSQFAwsVKkcECDkGGzQRAggPEg8GJkQOQjc0EwZcASkLDhEDUIFHBC9EgRYKAgQBJiSaeoFUCQEQFUY0KwsEFAkKJAYCBBMLJAoLCw0ICgxJBAEFAQQCFxEvDBgRkiKDc4pFhFOcSkdvCoN6i3GLQINOhiMWgkSBOYxmhmqORoJKYpZzd41Sg2yRFAYgARKEZgIEAgQFAg4BAQaBMjE6a3BwFTuCZ1IZD44gGYNZhRSKZAF1AjkCBAMBCgEBAwmIawEmgjEBAQ
IronPort-PHdr: A9a23:uwGXfBEmbs73CLjCS3ZH/p1GfiYY04WdBeZdwpYkircbdKOl8tyiO UHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLURJWhcAfhQd1BsmDBAXyJ+LraCpvG sNEWRdl8ni3PFITFtz5YgjZo2a56ngZHRCsXTc=
IronPort-Data: A9a23:lc2ys60QvNDqEwyHQvbD5Qpxkn2cJEfYwER7XKvMYLTBsI5bpz0Bz WAfXj3TPa2LNjCgeYwgYdnj/BgFu5eDzoVjHANo3Hw8FHgiRegpqji6wuYcGwvIc6UvmWo+t 512huHodZxyFjmGzvuUGuCJQUNUjclkfZKhTr+UUsxNbVU8Enx50kgzw7dRbrNA2LBVPSvc4 bsenOWHULOV82Yc3rU8sv/rRLtH5ZweiRtA1rAMTakjUGz2yxH5OKkiyZSZdBMUdGX78tmSH I4vxJnhlo/QEoxE5tmNyt4XeWVSKlLe0JTnZnd+A8CfbhZ+SiMaz7cma9g+R35urDzZg81x8 4VNto2TYFJ8VkHMsLx1vxhwGiV6O+hN/6XKZCn5us2IxEqAeHzpqxlsJBhpZstDpKAuWicXr 61wxDMlNnhvg8qsz7u9Rultrs8iN8LseogYvxmMyBmJUq15HsmbGc0m4/dl/StupcNJG83SX PY+a2RraizRTwRmbwJ/5JUWxbf02SaXnydjgFySorY6+S7dywtt3ZDrN9nUc5qBQsA9tkaet 27L+2DRCxoROdCewDzD+XWp7sfOhTv+cIMfCLP+8eRl6HWP3mUODAxDCQOyueG9hwi1XNd3J 0kd4CForKUu+gqsVNaVdxKirXGFux8GQNlBO+I/4QCJjKHT5m6k6nMsRzpFbpkts9U7AG1s3 V6SlNSvDjtq2FGIdZ6D3qqFsGyQGwYsFEgLNTMZTTBV49ryg6hm23ojUe1fOKKyi9T0HxT5z DaLsDUyit0vYSgjiv7TEbfv3m7Em3TZcuImzl6MBz/6s2uVcKbgNtL0uASKhRpVBNzBFjG8U G44d99yBQzkJamXlSqGTfkKGtlFDN7abWGE3jaD83TdnglBFlaqeYRWpTp5PkosY4APeCTiZ wnYvgY5CH5v0JmCM/cfj2GZUptCIU3c+TLNDay8gj1mOcQZSeN/1HsyDXN8Jki0+KTWrYkxO I2AbeGnBmsABKJswVKeHrlCgO53n3BlnT2CGPgXKihLN5LDOhZ5rp9YbjOzghwRt8toXS2Mq Y8EbpvWo/mheL2nMkE7DrL/3XhTfSRkWvgaWuRcd/WIJUJ9CXo9BvrKqY7NiKQ795m5Ytzgp ynnMmcBkQKXrSSedW2iNCs5AJuxBskXkJ7OFXF2Vbpe8yJ9Md/HAWZ2X8ZfQITLA8Q/lKIqF 6dUJZ3bahmNIxyekwkggVDGhNQKXHyWacimZkJJvBBXk0ZcejH0
IronPort-HdrOrdr: A9a23:2v6E1KjKwgJMMYJIb3bZArHnunBQX2R13DAbv31ZSRFFG/FwyP rBoB1L73DJYWgqNE3IwerwRJVpQRvnhPpICPoqTMiftWjdySaVxeRZjLcKrAeQYxEWmtQtt5 uINpIOdeEYbmIKwfoSgjPIaOrIqePvmMvD6IeurEuFDzsaEZ2IhD0JbTpzZ3cGPTWucqBJcq Z0iPA3wgaISDAyVICWF3MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWnW4j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrazMdZDsDksLlaFtyssHfoWG1SYczAgNkHmpDs1L/sqq iIn/4UBbUy15oWRBDwnfKi4Xim7N9k0Q6d9bbRuwqTnSW+fkN9NyKE7rgpKicwLCEbzYhBOe twrhKknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfdsRKEkjTVo+a07bWvHwZFiFP MrANDX5f5Qf1/fZ3fFvnN3yNjpWngoBB+JTkULp8TQilFt7TpE5lpdwNZakmYL9Zo7RZUB7+ PYMr5wnLULSsMNd6pyCOoIXMPyAG3QRhDHNn6UPD3cZeo6EmOIr4Sy7KQ+5emsdpBNxJwumI 7ZWFcdrmI2c1KGM7z44HSKyGG4fIyQZ0WZ9igF3ekLhlTVfsuYDRG+
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.98,296,1673913600"; d="scan'208,217"; a="87377102"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Mar 2023 08:55:44 +0000
Received: from mail.cisco.com (xfe-aln-003.cisco.com [173.37.135.123]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 32S8th0Q012567 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 28 Mar 2023 08:55:43 GMT
Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.25; Tue, 28 Mar 2023 03:55:42 -0500
Received: from NAM02-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.25 via Frontend Transport; Tue, 28 Mar 2023 04:55:42 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LhdPehkhYpWDFeYY7SKm4oSLioK1coEw7odwhWU4+WVL9xUS/mR/hg6suszL7j/n2gWf30cya79t8m3wy5UkcSV+eDBljOD/uEk7W2nvrlIOZCvzM44zpZ2EjLqutdNSWmfI9S1z2b31+rxQlBfJ6Q0JZU7jr4t7EWVSbcGE0t9cTm18+lW0lGoudpzhXR3ZcF9K+Wgt3BTOl7D9ulPziMa/AT4OoAH5IsUAWoGtu19RbB0SCPOGmYuv8jw1f7711zia8x7CNt2dkcBhOpA4mBvw/RI7UdSnE9+AUDmqIBWH674upozNl2VGV7ZodzIY0QGmBYIknlikhBDsRc3ZwQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iLgsHkK7sP4rpae0jZN8ddObTy2gC1WsnRw/hMLfs/0=; b=NLT+2CBGYb1yumk0bJTeqJy9DwYlDvFqZEyk+fhS2+ePP6KcTjpb9ZHA1XYDNWZHAioupUUOFlfat7gYsQHqulhH4sDkjV7L3lXawNOnwoqqWTVf1DvrzZbeHWAVaGSoDXeDOlqY6SPhU/hYCSqHgBRSIKhFUdS3rEhfysVzR9hmfl1P9hYCKb2c0tsIMY2AG/uqoINUCuRc1D1MZtnCsJapeldzP2tugxnfVZgmeVvAlzFgEIl/zgi0otu0QtdzTpONKV/voKFoI09rdsIiQmkMPF7Habre8BDwoaTgUVZUX4m30aUjLU5YXYuBn+baeXpY/GUbvrpg0P2ge0dGHA==
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.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iLgsHkK7sP4rpae0jZN8ddObTy2gC1WsnRw/hMLfs/0=; b=f9TuCtbeyOfabSTJKhjkXxZ+7d9ch8OgBqWb4+hSkDnyYmJppJTD1zDu1j1a535SEX90Eur2AUBFUuVu+er46YvFtg4bH87g7MOuK7KGG5dddDohWjVe8VGRT0r9ITt3wf8hC04piU29RbwH9T6ToioZHO7RFaVWxIER/NvP6Ek=
Received: from BL3PR11MB5731.namprd11.prod.outlook.com (2603:10b6:208:352::15) by PH8PR11MB6657.namprd11.prod.outlook.com (2603:10b6:510:1c0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6222.33; Tue, 28 Mar 2023 08:55:39 +0000
Received: from BL3PR11MB5731.namprd11.prod.outlook.com ([fe80::aaae:8d72:76dc:ef72]) by BL3PR11MB5731.namprd11.prod.outlook.com ([fe80::aaae:8d72:76dc:ef72%5]) with mapi id 15.20.6222.033; Tue, 28 Mar 2023 08:55:39 +0000
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>, Henrik Nydell <hnydell@accedian.com>, "Foote, Footer (Nokia - CA)" <footer.foote@nokia.com>
Thread-Topic: [ippm] WGLC for draft-ietf-ippm-stamp-srpm
Thread-Index: AQHZH7IQNE+asB/YvUqUgkUOBQ6GN66ZxOsAgAA4GgCAFZRVSIAIR2aAgADZpnWAAkRsgIBTtr+3gAG3obM=
Date: Tue, 28 Mar 2023 08:55:39 +0000
Message-ID: <BL3PR11MB573158F8A4549ADC578AE4D7BF889@BL3PR11MB5731.namprd11.prod.outlook.com>
References: <8D63B647-70A8-4CAC-96D0-9666010144DB@apple.com> <CA+RyBmUWsm_QCXtaibAH+zPTdu2+KrUjuiG3JeonivEoa-2AHA@mail.gmail.com> <CA+RyBmXYAQ5=Bfa1_y5TmnDH8GHxaJXMyH-ST7F1V5B9VUaYgg@mail.gmail.com> <BL3PR11MB57310973095FA301154863F1BFCE9@BL3PR11MB5731.namprd11.prod.outlook.com> <CA+RyBmU2fK6_wCknC8WO9Er3ZSTz6OicPvmhJrt=+HkaRgKO5A@mail.gmail.com> <BL3PR11MB573160D91EF48615C27D2380BFD09@BL3PR11MB5731.namprd11.prod.outlook.com> <CA+RyBmUeX34YtOmqS9Gw6zk_JCMqJJfc28qj8jbq9HFd90iXdg@mail.gmail.com> <BN0PR11MB574269DD0D882F79A75D3C99BF8B9@BN0PR11MB5742.namprd11.prod.outlook.com>
In-Reply-To: <BN0PR11MB574269DD0D882F79A75D3C99BF8B9@BN0PR11MB5742.namprd11.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL3PR11MB5731:EE_|PH8PR11MB6657:EE_
x-ms-office365-filtering-correlation-id: 90feda25-98a4-417d-9aa7-08db2f6a3446
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EE70SUgD/cAvcS3bjE+PkVOUXfZzFZliW30Z+8X/GUxG2/QnlYOD+k6mCZMxV5FveDFlX86x4RtRlihrVn3BOeGhFPwR3H+jpFdQTHHfD/8tXYFSfVcHHHPO8u5wOW11yhdEr0E11ioanVu9dEtZIRn8ruaEc/e6XlajtJZW+VGrAASEhlb9BH7NaSfPwlI5J2pvDjcGsj9pMl+8APGLtPSpkpd6PtbECRHrktdIOvr+cmCAheSTR+4M2Y0WgHwezHZNPp0aze/N5ia0iJDa36k7YiOe7Ylf83WPNcqPDPh+fePSVxyPDu7OrGDmfFyyfUhpjMMWPUoiRXAGNiaHuonH0uDuputtFXAmokLGIXOYtuQRtQBOVHgPOg8itbXbyeSKg/hOWftpQd9KIw2hIRv9sOJpS5dxctlYy2FMbq1npFM3rbL/UEro4798MV1AM76cpE8XlptR8uKtP0kplVthY6imDozGdjQnG09/+0f/JVOVKMK3FkoY4nS5pnuXeH/V5356tWVzJ/H4jHB0JifoiLh+5ea3gbFgUnvM4naqXROM+Jyy9culz4pNYVqyK2doICFQChoU4XxkdojyH2Q226buk+ujLN1kdQMzZc+3LSUjZDywcgkXb/3F+VltCt6kM+A2g5YV+TLycefs5Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL3PR11MB5731.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(376002)(396003)(366004)(346002)(39860400002)(136003)(451199021)(76116006)(91956017)(66946007)(66556008)(66476007)(66446008)(64756008)(8676002)(41300700001)(6916009)(52536014)(55016003)(166002)(4326008)(2906002)(38070700005)(5660300002)(9326002)(122000001)(38100700002)(30864003)(8936002)(21615005)(9686003)(6506007)(53546011)(966005)(33656002)(83380400001)(186003)(54906003)(316002)(86362001)(71200400001)(7696005)(478600001)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 4ky++Z+2+VC12iYA7p6kvlE/xp07UzCe4Ru5eBVWn628Ic3Xo1IqT52r8WZj9relF0Ao8zrwS79w/vJLgnNjt6/tOt7DChUjk1YZFuhypizxGaI0h+rhu9YnUEmPJiyMuQI5jBEDLDc+/1EBpHuukeTy3r6yI/aqXS07SOTI81J7WbT2noi8OH5Cyv95lS3EnxeNSaCbarjcfsz1l4D4ffviANvAWCjT5Tj0S2oyL5iIzKFXCAwY5s4KHIQ4ftAQjMQPlai3me0kWT3YojN9GTRBSVVHy7rNlDleJT1pImI4+ju7Xnulfac1jgV31nIKzfrQ76mWBf3ZwftLl8wr4Ite8D9dI0lkrjxXCbu5bDH/qHYmHGBuez0qb+0WCp+ervSVonrpL/Yq+98T+sZbHRby0caDPBE4w64ZKHsuMmJlKIjQkeAvLILG5OMTxiaqZJVFpExHiAaFXPxAzUy0sCGUdvfRaBneRwZIzXqwTRXlDhNkmWNC6AVP1y1Wm7KccgLY14ybwBnMCQBJeIsqdgHcfD/VlU0CBOG3ucrjWazpDym5DD5AnJFLn5krR0R1hzRZwROgx9henuJkrgX9Vrbtm0BkGi6oBzCdKctYN7IFRX+dpUUVlvA9PWTc9zOUoKC8S8Wco+ZEc6r3j1BAyElQFIcI7Y3r496kzGBuS3zYLcWJIZ+nLSke90hssA8U2+ygagxwjzalMqlrE9WXtjj+dOf0SXbFH1DhEvm8hKqlvpFcQH4rqG6wLiiluOrAkiv2W3PPxonwXWheN2YS4XqVT7rLrF88r4Bcd9i+DQZ+vsqjCh3vE4UeZ64/Y70hWdPndhDws2mwynPX1ZRezhRduM2TEp1I7radPQ1w7WHHPd8MxUxn8SVK7HYk396L6A8nXekjzefXVUh37+JkfkwOrC/GbLJc+/rnG3k0yXu504KeeJrrb7REkpfxwGri37GGxu+dRZv854VqXQlzYUoLp52yYqHGLIJXuSiWQJaL30CyONmFU5kx3gOolfJWa4MpCCgd/64DvJiaU/p4fP4Ca9eh7IuKl4KMgPce1dCkEWt4hkzniUdbOt3HYmMAoHSZA99gsWKDz+3svMC7R1JdRUwHSGdBPiZiX7KjZ/+jT3S3Wr4IT+NYslocY7AJqpp2a9/btihaHBg11FELG3A2TSP+qoO2HRtUEi9Zb0jck5yDx9IUfVbqZjtomuCDqyEoKdkBR8D7a1stA1A9DV4VsSPDFDoRLHH97RLiaP9/siVvAEus38YEH46wEpKC5C9H4/XvNoHj8Re3Milk1m1RUV6pSWsVSmarP4GeOiqPdIpPUlsdNAEFwNVYwtddTCmuOp4AR/NxdSSVtZsVUX8JXQ6YoLmmppgLOxGhbZW2Q0qMt+JgOOQwW3WFldIjZl4k+5Kb09KUpNSghT2Z11dDF5xilsRtSrYwd6JbWG2yJKEZqYG2DdIArlRHWnML5UeT2UsE7W7z9iCtyi0HN85JAwC+EaLQ95YFRno78368DUySuwCtWrtDVfEVAa9qXDPrHw4XwCbTIwzDRIEQmRJrjIBl9T7oyIyqWdJa+OLNDTEW4n/7iGkx0snKJlGQc4yDJ3jeh1+7Q1amzbCle48zWyK0bpROqR1CuPEuwelctsb2BoHvBppe7eW6S8WUV6wg635pxcWVxGGHH0m1Sw==
Content-Type: multipart/alternative; boundary="_000_BL3PR11MB573158F8A4549ADC578AE4D7BF889BL3PR11MB5731namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL3PR11MB5731.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 90feda25-98a4-417d-9aa7-08db2f6a3446
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2023 08:55:39.2885 (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: HEV2wPRGr0QF2iGGGav/HGkFvzRQ+93C5miJWnTCRQqoxb8eqh7rJUcUXcJB1t+U6k4agK+B2HPgfsxZeDZVOQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB6657
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.135.123, xfe-aln-003.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/HWEECo-73A6WaplITDBc6hRqHV4>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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, 28 Mar 2023 08:55:50 -0000
Hi Greg, Thanks for the in-person meeting and discussing the review comments. As discussed, we have moved to use the U flag instead of the V flag for the error cases in the draft now. Hope this addresses your review comments. There is an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-09.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-stamp-srpm-09 Many thanks for the fruitful discussions. Regards, Rakesh From: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> Date: Monday, March 27, 2023 at 4:13 PM To: Greg Mirsky <gregimirsky@gmail.com> Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>, Henrik Nydell <hnydell@accedian.com> Subject: Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Thanks you Greg for detailed review comments. Sorry for the delay in replying. We can further discuss off-line this week in Yokohama if needed. Please see replies in line with <RG>… From: Greg Mirsky <gregimirsky@gmail.com> Date: Thursday, February 2, 2023 at 9:13 AM To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>, Henrik Nydell <hnydell@accedian.com> Subject: Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Hi Rakesh, thank you for posting the new version, it helps to track our discussion. I have several notes on the updates and their possible impact on the existing STAMP RFCs: * The example in the last paragraph in Section 3.2 brings some concerns: * you use the Direct Measurement TLV from RFC 8792 as an example of using the new V flag. Is it your intention to use this draft uprating RFC 8792? If that is the case, please mark the draft accordingly. * Furthermore, I cannot understand the relationship you are referring to in the example. The Stateless mode of a STAMP's Session-Reflector is not expected to affect counters that a system maintains outside the STAMP implementation. Thus, I'm not at all convinced that a Session-Reflector in the Stateless mode will benefit from the proposed V flag. <RG> Ok, authors agree to move the behavior of the V-flag for TLVs in RFC 8972 to a separate draft in future and limit the V flag applicability to the TLVs in this draft only to contain the scope of this draft. * Based on the abovementioned reasons, the only application of the new flag introduced in the draft is to verify the consistency of the control plane and the data plane from the Session-Reflector's PoV. That is clearly outside the scope of STAMP as defined in RFC 8762. At the same time, verifying consistency between the control plane and the data plane is part of the functionality of, for example, RFC 7110 Return Path Specified LSP Ping<https://datatracker.ietf.org/doc/rfc7110/>. For an SR-MPLS environment, an operator can use the non-FEC TLV encoding of MPLS Link Switched Elements defined in draft-ietf-spring-bfd<https://datatracker.ietf.org/doc/draft-ietf-spring-bfd/>. Thus, I conclude that there's no technical need for the Verification flag, and for two-way performance measurements, STAMP can be used in combination with the existing Fault Management OAM tools. <RG> The V flag is for verifying the fields in the “STAMP packets” and replying to the Sender accordingly as described in the draft. We can sync-up off-line in Yokohama if needed. * Regarding the choice of the destination IP address in an ECMP environment. If it is in an IP/MPLS network, then the MPLS WG recommends using the Entropy Special Purpose Label as the indicator that the next MPLS LSE includes the value (Entropy Label) that can be used to load-balance flows. Also, the example only suggests that load balancing be achieved using the IPv4 address family. What can be recommended for an IPv6 case? I imagine that in the IPv6 case, load balancing can be achieved using the Flow Label in the IPv6 header. If you agree, and the scope of the draft is a Source Routing domain, I propose to simplify the specification and use a single IPv4 loopback address, e.g., 127.0.0.1. <RG> We have updated the section 4 in the published draft to further clarify the usage. * What is the expected behavior of a Session-Reflector received Reply Requested on the Same Link request? It is not clear as the document lists several options - "physical interface, virtual link, or Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member". How does the Session-Reflector that received that instruction choose between, for example, LAG and a LAG member? <RG> Ok, we have added following text to cover LAG member: When using LAG member links, STAMP extension for Micro-Session ID TLV defined in [I-D.ietf-ippm-stamp-on-lag] can be used to identify the link. * The last paragraph in Section 5.1.2 mentions that the Return Segment List sub-TLV can communicate a p2mp segment list. If that is the case, the Session-Reflector will effectively transmit the reflected STAMP packet to multiple receivers. What is the purpose of that behavior? What are the requirements for the systems that terminate that p2mp SR tunnel? Using a p2mp SR list appears as a dangerous attack vector. <RG> Ok, we have removed the P2MP text to contain the scope of this draft. Thanks, Rakesh I'm looking forward to continuing our talk. I hope that other experts in the IPPM WG will share their thoughts. Regards, Greg On Tue, Jan 31, 2023 at 5:49 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com<mailto:rgandhi@cisco.com>> wrote: Hi Greg, Thank you for your further review comments. Please see replies inline with <RG>.. From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> Date: Monday, January 30, 2023 at 7:36 PM To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com<mailto:rgandhi@cisco.com>> Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc.ietf.org>>, IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>, Henrik Nydell <hnydell@accedian.com<mailto:hnydell@accedian.com>> Subject: Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Hi Rakesh, thank you for sharing the updated version. Please find my notes about the updates and the draft below: * Section 3 now describes some optional behavior handling the U flag. I agree that these options are valid but must point out that other behaviors are possible. For example, a Session-Sender will continue transmitting test packets despite receiving the U flag set in the reflected packet. I imagine an intelligent implementation will merely ignore the TLV with the U flag set and report that, along with the collected and calculated performance metric and/or operational data. It seems logical to expect that an implementation of STAMP that supports RFC 8972 and this draft would set both U and V flags. Thus, as this is an implementation choice, I think introducing the V flag that effectively duplicates part of cases already addressed by the U flag is unnecessary. <RG> In case of U flag, the unsupported TLV will never work (until node upgraded) whereas in case of V flag, the TLV (as supported) should work, so need to troubleshoot the networking failure😊 Yes, the sessions can still continue to transmit packets in both cases. * The reference to RFC 9256 is helpful, but I couldn't find that the RFC defines the use of a loopback address. As there is no requirement to use the loopback IP address, I don't think the document should make it such. <RG> It is the Null Endpoint. “ https://datatracker.ietf.org/doc/rfc9256/ 8.8.1. Color-Only BGP Destination Steering ... The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits set to the 0 value).” * An example of using an IPv4 loopback address in an ECMP environment is unclear. Wouldn't using a routable IP address be better for an operator? <RG> Added additional text in Section 4, paragraph 2. * Thank you for adding details describing fields if the Destination Address TLV. Do you think that the Length field description can further benefit from specifying valid values for it? And similar question for the Length field in Section 5.1.2. <RG> Updated. * Thank you for clarifying interpretations of fields in Section 5.1.1, that helps. Do you think that the Length field might be set to a value that is invalid? <RG> Updated. * Section 5.1.1 defines the Control Code 0x01 as "Reply Requested on the Same Link". Is that a physical or logical link? <RG> Updated. I appreciate the work the authors put in addressing my comments. I hope that the authors will also address Henrik Nydell's comments, particularly, adding considerations for interworking between STAMP and TWAMP Light systems when using the new STAMP TLVs and sub-TLVs. <RG> Added in Section 6. Thanks Henrik for the review. FYI: updated drafts can be found at: URL: https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-07.txt Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-stamp-srpm-07 Thanks, Rakesh Looking forward to our continued discussion. Regards, Greg On Wed, Jan 25, 2023 at 10:31 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com<mailto:rgandhi@cisco.com>> wrote: Thanks Greg for reviewing the document and providing the comments. Attaching the updated draft and the diff file. Please see replies inline with <RG>… From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> on behalf of Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> Date: Wednesday, January 11, 2023 at 7:39 PM To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc.ietf.org>> Cc: IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>> Subject: Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Dear All, I realized that I have several additional questions: * What is reflected by the Length field in the TLVs defined in the draft? As I can see it, the field is two-octet long. Can its value be any number between 0 and 65535? <RG> Added Length field description in the updated draft for all TLVs and sub-TLVs. * Also, it seems like there too few descriptions of the fields of the defined in the draft TLVs. <RG> Added in the updated draft for all TLVs and Sub-TLVs. Please let me know if any field is still missed. * Returning to the Verification flag discussion. In Section 4 of RFC 8972 we defined three flags that have a single TLV scope. Among these flags is Unrecognized (U) defined as follows: U (Unrecognized): A one-bit flag. A Session-Sender MUST set the U flag to 1 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the U flag to 1 if the Session- Reflector has not understood the TLV. Otherwise, the Session- Reflector MUST set the U flag in the reflected packet to 0. It seems like the Urecognized flag can be used to indicate functional mismatch between the request expressed in the STAMP test packet by the Session-Sender and STAMP capability of the Session-Reflector. Hence, I don't see a use case to introduce the Verification flag. <RG> Added additional details in the first paragraph in the updated draft in Section 3. <RG> Please see further replies below. Regards, Greg On Wed, Jan 11, 2023 at 1:17 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote: Dear Authors, thank you for your work on this document. I read the latest version and have several questions and notes: * It seems like the rationale for introducing the Verification flag is to differentiate between the Stateful and Stateless modes of a Session-Reflector. Is that correct? <RG> Both modes. It is clarified in the updated draft in Section 3.1. * I think using configuration information or other out-of-band discovery of STAMP capabilities is more appropriate than a Session-Reflector dropping a test packet if one of several requested actions cannot be completed. <RG> Ok. * It is operationally more valuable to return information to the sender, indicating success or failure in performing the requested action. Dropping the reflected STAMP test packet because of the failure of the Session-Reflector to perform one of the requested actions does not provide useful feedback to the Session-Sender, as it cannot be easily differentiated by the Session-Sender from a lost packet. <RG> Ok, removed the “drop the packet” texts in the updated draft in Section 3.1. * If there's a belief that some STAMP extensions need further specification for the Session-Reflector Stateless mode, a new document should be presented. <RG> I don’t see any need for that. * It is not clear to me why in the case of SRv6, the Session-Sender will use the loopback as the destination IPv6 address rather than the actual IPv6 address of the Session-Reflector. <RG> Added a text for this in the updated draft Section 4, second paragraph. * Nit: probably s/that is supports/that it supports/ also s/may not reach the intended/may reach an unintended/ <RG> Fixed in the updated draft. Many thanks Greg for the detailed review. Thanks, Rakesh Regards, Greg On Tue, Jan 3, 2023 at 12:29 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc.ietf.org>> wrote: Hello IPPM, This email starts a Working Group Last Call for draft-ietf-ippm-stamp-srpm. As discussed at IETF 115, this document has already received its early allocation and has been stable for some time with no open issues. https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-06.html https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-srpm/ Please review the document and provide feedback to the mailing list on any comments you have, and if you think the document is ready to progress. The last call will end on Friday, January 20. Best, Tommy & Marcus _______________________________________________ ippm mailing list ippm@ietf.org<mailto:ippm@ietf.org> https://www.ietf.org/mailman/listinfo/ippm
- [ippm] WGLC for draft-ietf-ippm-stamp-srpm Tommy Pauly
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Rakesh Gandhi (rgandhi)
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Voyer, Daniel
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Tianran Zhou
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Greg Mirsky
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Greg Mirsky
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Zafar Ali (zali)
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Gyan Mishra
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Pablo Camarillo (pcamaril)
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Haoyu Song
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Ahmed Abdelsalam (ahabdels)
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm li_zhenqiang@hotmail.com
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Mach Chen
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm xiao.min2
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Henrik Nydell
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Tommy Pauly
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Rakesh Gandhi (rgandhi)
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Greg Mirsky
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Rakesh Gandhi (rgandhi)
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Greg Mirsky
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Rakesh Gandhi (rgandhi)
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Rakesh Gandhi (rgandhi)
- Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm Greg Mirsky