From nobody Fri Jan 27 04:39:28 2023 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9ABC14E514; Fri, 27 Jan 2023 04:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, 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="muP9poLg"; dkim=pass (1024-bit key) header.d=cisco.com header.b="BEIN23HR" 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 s6B7ZGRD9PAM; Fri, 27 Jan 2023 04:39:23 -0800 (PST) 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 36BC3C14F5E0; Fri, 27 Jan 2023 04:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15821; q=dns/txt; s=iport; t=1674823163; x=1676032763; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m+1oJHYdmWpgpfLrjvInLFLiDsxMWqZGxvQ1Ek5OMQE=; b=muP9poLgXzs8NAKEiZsipRIXrJ71c05ukSfPsO/8XgAqaRNjz69fL+ja FET2RYC2w9JsOyjLvW6WeTpTreg4lehFp0uI+PYGWiXZFJDXXCAXbCN60 CR7YGWfKy5xkMmu9396STmxTXXCGG8J6rvpf0n0RDRaTOFgQJ9RG7iZ9J k=; X-IPAS-Result: =?us-ascii?q?A0AYAACUxdNjmJldJa1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?TsHAQELAYEpMVKBBgJZOkWIGgOEUF+IIQOWc4UegSyBJQNWDwEBAQ0BAUQEA?= =?us-ascii?q?QGFBwKFIgIlNAkOAQIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEFAEBAQEBA?= =?us-ascii?q?QEBHhkFDhAnhWgNhlUBAQEBAxIuAQE3AQ8CAQgRAwECDiEyHQgCBAENBQgag?= =?us-ascii?q?lwBghaBDAMBnVQBgT8Cih94gTSBAYIIAQEGBASfHwmBQAGJDogYJxyCDYEVQ?= =?us-ascii?q?4JnPoJiAoFIGh6DcYIuj0k1gWeBWIgeCoE5d4ElDoFGgQ8CCQIRdBwHNgNEH?= =?us-ascii?q?UADCzsyCj8UIQYFC0orGhsHgQYqCR8VAwQEAwIGEwMgAg0oMRQEKRMNJyZpC?= =?us-ascii?q?QIDIl8FAwMEKC0JHwQcBxURJDwHVhIlAQUCDx83BgMJAwIfUHslJAUDCxUqR?= =?us-ascii?q?wQINgUGHDYSAggPEg8GJkMOQjc0EwZcASkLDhEDUIFNBC9EgSMCBCkmnykXU?= =?us-ascii?q?RQ3gQcESA8SEQURIKEPjiOUBgqDc5pnhh8WqE5el04gok+EeAIEAgQFAg4BA?= =?us-ascii?q?QaBYjqBW3AVO4JnUhkPjiAJAw0Jg1CPcXU7AgcLAQEDCYwjAQE?= IronPort-PHdr: A9a23:3xBhsRE6pR4t11KHi72RGJ1GfiYY04WdBeZdwpYkircbdKOl8tyiO UHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLURJWhcAfhQd1BsmDBAXyJ+LraCpvG sNEWRdl8ni3PFITFtz5YgjZo2a56ngZHRCsXTc= IronPort-Data: A9a23:50/WRKjItzeo32yI4J0FlLDOX161XBAKZh0ujC45NGQN5FlHY01je htvCmzVMvqINDCnctonOo/i8xsAvsfSytI1GwBk+S82RipjpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKkYAL/En03FFAMpBsJ00o5wLZg2NEw27BVPivU0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pDTU2FFEYUd6EPdgKMq 0kv+5nilo/R109F5tpICd8XeGVSKlLZFVDmZna7x8FOjzAazhHe3JrXO9IfZWxc1i/SwOlzz fVTvJyhS1grYY/1zbF1vxlwS0mSPIVc87PBZHO4q8HWlQvNcmDnxLNlC0Re0Y8wo7ksRzoRs 61DbmlQNXhvhMruqF6/Yu9lms0nBMLqJ4gY/HpnyFk1CN58HcCfHf+Sure02h8IqcJJBc/dR /Y8cBdOSwjccy1GfVQuXcdWcOCA3ymjLGIwREiuja42+HD7zQFt3v7qKtW9UtiDXtkQlU+co krH8nj3RBYAO7S3xSCM/G7ph+LTk2b/WZkKUaWl/OV3ihuawmg7CRAKWx28u/bRolSiVJdTK lY8+ycyo+417kPDZtz4VBeioXKJ4TYTXtNRF6sx7wTl90bPyxySCm5BRTlbZZl88sQ3Xjctk FSOmrsFGACDrpWWRVmWq63P8gqwPAgLJG8TZ3AGEik8toyLTJ4IsjrDSdNqEaiQh9LzGC3tz z3ikMTYr+hN5SLs//jglW0rkw5AtbCSEVFovlS/snaNq1ImNNT8NuRE/HCCta4YRLt1WGVtq 5TtpiRzxPoFAZfInyuXTaBXWrqo/P2CdjbbhDaD/qXNFRzwohZPnqgJsFmSwXuF1O5eKFcFh 2eI42tsCGd7ZifCUEOOS9vZ5z4W5abhD8/5cfvfc8BDZJN8HCfeon4yOhPPjzu0zxZ9+U3aB Xt9WZvzZZr9Ifk5pAdau89GuVPW7nlknDiKFcyTI+qPiODDPBZ5tovpwHPXPrxms8toUS3e8 s1UMIOR2g5DXejlChQ7AqZNRW3m2UMTXMisw+QOL7brClM/RAkJVaSLqZt/INMNokigvrqSl p1LchUGmAOXaLyuAVjiV02Pn5u0DMcu8yxjbHR2VbtqslB6CbuSAG4kX8NfVdEaGCZLlJaYk 9Ftlx28P8ly IronPort-HdrOrdr: A9a23:jLh3ta/IzcaF8VpLGG5uk+Fmdb1zdoMgy1knxilNoENuHPBwxv rAoB1E73PJYW4qKQ0dcdDpAtjlfZquz+8L3WBxB8buYOCCggqVxe5ZnPPfKlHbak/DH6tmpN pdmstFeZHN5DpB/L3HCWCDer5KqrTmgcOVbKXlvg1QpGpRGsZdBnJCe3+m+zpNNW977PQCZf +hz/sCgwDlVWUcb8y9CHVAdfPEvcf3mJXvZgNDLwI76SGV5AnYp4LSIly95FMzQjlPybAt/S zuiAri/JiutPm911v1y3LT1ZJLg9Hso+EzSvBky/JlawkEuDzYJ7iJaIfy/gzdZ9vfrWrCpe O84yvI+f4Dr085MFvF5icFkDOQrgrGo0WSuGNwx0GT5/AQgFkBepJ8bUUzSGqB16NohqAN7I tbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0WbWIyUs4mkWUkxjIdLL4QWCbhrIw3Gu hnC8/RoP5QbFOBdnjc+m1i2salUHg/FgqPBhFqgL3e7xFG2HRii0cIzs0WmXkNsJo7Vplf/u zBdqBljqtHQMMaZb90QO0BXcy0AGrQRg+kChPYHX33UKUcf37doZ/+57s4oOmsZZwT1ZM33I /MVVtJ3FRCDH4Gyff+qKGj3iq9NVlVBw6duf22z6IJyIHBeA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.97,251,1669075200"; d="scan'208,217"; a="24846207" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jan 2023 12:39:21 +0000 Received: from mail.cisco.com (xfe-rcd-001.cisco.com [173.37.227.249]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 30RCdLtk028452 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 27 Jan 2023 12:39:21 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Fri, 27 Jan 2023 06:39:21 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.15 via Frontend Transport; Fri, 27 Jan 2023 06:39:21 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FQh6dP2wqMsbRpJesn220ET71gogx3KJQLNLNf/ut1l7AJt93AyGatvNySBC4la7Tl7ptj5F3R/Fmf7cMAY3tMgGC+vrdJqLiZ9hgubn6Y9JB3H6WrQ3qE5x0zXzIkAajD7Edh0ENsrQrvYJR3LVy5TwNsW9nOTmqpryEgqfZOfE4+meRXHcPe6kvLO8anB5/2mNfvEQiRNipZU6C8hplAYtrwpgNmazLAF4OFRABPrDaD+295GD3FHkaY0QiHP9MHThWfx6Y+cC0Lr475wRXTvp3II+t2z4WTgdDJwfSk08QoSHq9/ExLpUxA5Y83HHxfA8ngThuJVdi+icXbk5Fg== 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=S1TBxv7nIkpNfXKsiv72R9Lii9cxs+mmlH7MGhmf1Zg=; b=aJL0zMndxU6v3FlTYu34KqsnYJua9Jd+CxROLJOrxwH2Yt5tNMP4wZVUCaLpDC8d9htiVeofdIQQQwwCX1/tYUFzhLgRpSH/HDv4d4dN/qI7r6L+tDQDJFVpEABY6bTai8hpcpantq9ROWv2KhRFkC9O45kf8XDDJn9T4XYAv33m5emGaKCxP/zev9riGu3yobLn9nS5b9Lf3T/1aBltpDgKTiKf60skXdNhN1CQhxUMPGnK0TPo/OJ1L576KFGX0cUR78akSpplU2M4QxGsrfv+4pcQvBLw/WOmz0KN5n2vymjWRz4IE48t4oHpHhR0UtCrf/CJj416tDxkIKhPew== 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=S1TBxv7nIkpNfXKsiv72R9Lii9cxs+mmlH7MGhmf1Zg=; b=BEIN23HRwlwtbMpXZn6gAmnKtAKoCOlMbyqrQLiovAyQzAcq5swNA7fZVjTassnMeTi7/7B0jptcS7Ruh6CVekWnnzyqz89nlfd9JVQ/QBJBpbGCVdovwE5TKOsdJC+M/vI4Pzu95hrfC8CsCo+2KDtQApHd57WR8UGFoRYShxo= Received: from BYAPR11MB3591.namprd11.prod.outlook.com (2603:10b6:a03:b4::30) by DM4PR11MB7182.namprd11.prod.outlook.com (2603:10b6:8:112::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.25; Fri, 27 Jan 2023 12:39:19 +0000 Received: from BYAPR11MB3591.namprd11.prod.outlook.com ([fe80::ad7a:87df:414e:3f65]) by BYAPR11MB3591.namprd11.prod.outlook.com ([fe80::ad7a:87df:414e:3f65%5]) with mapi id 15.20.6043.023; Fri, 27 Jan 2023 12:39:19 +0000 From: "Alberto Rodriguez-Natal (natal)" To: Mike McBride , "rtg-dir@ietf.org" CC: "draft-ietf-lisp-pubsub.all@ietf.org" , "last-call@ietf.org" , "lisp@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-lisp-pubsub-10 Thread-Index: AQHZL7Btt30cKQAVzku8M6LQyEgInK6yOEZG Date: Fri, 27 Jan 2023 12:38:59 +0000 Message-ID: References: <167453622962.572.17548527673007108094@ietfa.amsl.com> In-Reply-To: <167453622962.572.17548527673007108094@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US 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: BYAPR11MB3591:EE_|DM4PR11MB7182:EE_ x-ms-office365-filtering-correlation-id: cbc62a82-badb-40aa-8015-08db00638284 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: k24K5ysSOjQx97cKaxUZlIuMLKmTdgrVZ4OC5VQXcR26+cSKODMSFcI9tv94xYtwowlaQwcdxG7LQ5DXcxUx0ZVLEwzN9qLxX3TaKDR/d6gdCGJrUjYNmHfa9GFik+hOUgVrNBO8LmUgqBTH6ArnYGolWgUprrXQDII4e5oMD/8nTFImTbPMtoTs+61dNeUJjKgvH+S8wn6BxXK6z8BdFucNrn/rkg4jCWZvCbpMy+WNKlR+3SzokBYCntdrm6E51RHNBVJokHnBcsob0eyZBLD4LGIRwO6nitprqqBn+EtWxjBTs2yq09GdUF+xtxSz/jjRS6K56ro+CEe5ULYJFzfg9yGGMEE340iS1w4CZ9mFsOD2rTAONZycby6cztbnM87NnXw0vHOIjFZJPlzzVsghLxCQ73LKyQDKrocSvCMReEP6a6kY+rSvoEJH+DLfsKOOYIVvHjsd0rCi+45XFQmYHQf4e+T4iYIq0lEPMyLWuB0RD0yD1RcGrFYfvaZ3knyd4AeAfQlKkp9hiC3Qpfs8UPHDjVDSaOjEi5PlTq3kj09PNDmj+q4rJBCftWtp1u5yTLT+jR7zJ8Rrw9QZ5KXIjOXFUxFzOoE9cglx0dJQqSzybJxiobGdw/iZnEF6EcPM89rWyNkVzd7h0S3poSyhb0sQD54I8dudLy58CLUYRfFcYvCzHozUnjszLDBAob1fTeYUF23j8Yr3lu+S/Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3591.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(366004)(346002)(39860400002)(396003)(376002)(136003)(451199018)(41300700001)(83380400001)(86362001)(54906003)(110136005)(316002)(6666004)(478600001)(7696005)(33656002)(53546011)(186003)(9686003)(26005)(6506007)(71200400001)(4326008)(91956017)(76116006)(8676002)(64756008)(66446008)(66946007)(66556008)(66476007)(38100700002)(2906002)(38070700005)(8936002)(52536014)(55016003)(122000001)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?qRP3FoSz7H/HZqw8b6mDeChEsCKQRz6HuXL3o0iu5+XQ155TqTV7tJ/Gn52m?= =?us-ascii?Q?T/4vEvDAabL4CxTALSW5jSLypjYHQj7OlkXDlMMzsh4MvZVX4Q8iPGU9YQxk?= =?us-ascii?Q?bYwpjd5dNbuphesNJmEFu5sqsBu6p3EkrxrNd+pdFQfQU2SbTLJfAF97ah9w?= =?us-ascii?Q?1EdUjIoRidPafEq+n3uRQA8bcKBIXTArZlQxm0WotDQeWnNHpe2xxKhVFDqq?= =?us-ascii?Q?JIqipYlec6x4SjzsLecIKXYFQIcsit631j4tMWXxzyP96miMqTBOID15OTvU?= =?us-ascii?Q?8zB2OQ6MAC0nPHQk7xdgay4Rta/ujrhdicw//S05G6nPUTuiMJhxqXup9I4t?= =?us-ascii?Q?TkoGWa6loHCeDgjvL6l7iapRWIFlpCGo/ja6XpswyWBQKsqi9Bgu7KFMHmHr?= =?us-ascii?Q?0tAupcJWAHYlim8HHSXDZfnPR1ky38rLWGZ5kXdS7jtApgtdFmg62uaLQe76?= =?us-ascii?Q?kwp+GkcJ4ULWn8WLVwbF8MBrN4CPUXL1l8zBnBlqnV3PV4IgqUCUs3wdW/nt?= =?us-ascii?Q?KQ82qwnlTTiVkTFbxPccZx49Os8fkFvX9xcpXSgxEpYRVlRALA/LwI57BB6X?= =?us-ascii?Q?bfHC2wg4aiElZYSf+sdPkHM2shLFPTC6rFPiwl42k4bol3503UADwPPRVXSC?= =?us-ascii?Q?Kl7S3E4OhI4u4AIuhXqdK5A7EX0pxoSTVt/9Jg/LIPXtWMGxNj4KYn+tAV9T?= =?us-ascii?Q?bQeUEkoJT373Aei9yF92hXkEzKJpDsrDX77U6hA1ZbWDpf1cXHLczxXrgbvp?= =?us-ascii?Q?a/MjirHmzXLRID7SP63jzZWZAqbKMfQ51KdcuHPxR8FJ41VivK9Rr8/3shrI?= =?us-ascii?Q?bOkPn1XgtUjonniczakHXhfCtDMoPJjU7OCrYgDJy/dglDUEBEqytaYtSjf9?= =?us-ascii?Q?Dd5bYSuIkuI7oFc3kH315rFouYn2hgCMPUC/JjakbRTnCGDGD6SzqbvOTonE?= =?us-ascii?Q?NH9HVyVMs+D4WVg2Aon4O2arxcn0f88Lo5SRRKbWW8W60QkqR41JltaTqb1m?= =?us-ascii?Q?OJTTQTA8+Cu23TP4b6X5dGjalT3d0IlORtHEhiyhThkjpEtgF2cAtLbYuxQ5?= =?us-ascii?Q?IDLiBJg1ePVR7XCv9ZhXBCZ2SxorKdCQX7It4L9a/7pOXhygJITHFn+2c/ew?= =?us-ascii?Q?yP4g/21HjMs+0tMcYv6U7OxsjqKs55gA2+Hg9CdSlRNZtMdLcmqz6OTZ3Rag?= =?us-ascii?Q?8RWWhcPJ6NDGOXaD852CpbxhpWyoeCLDCKKi78eWFpAvwfH5D+qmDaYTp1Hu?= =?us-ascii?Q?yqwyZLunl9hNfsUn0TbDtUqUHhKE/b35MUuW8tKXu1ZOiXg6hVQ2UFvQJIcs?= =?us-ascii?Q?Q+L5fD0NH4iLzpY6vDg+kAiv0iR6Kikm1Ka2mdKv/84Lhc8uwIPEE1otu5YH?= =?us-ascii?Q?mKBOpYqEWikP8g8emVlfM8ctHLep4OPmd2OdYdy7KiaYjtQz2gOtlczijJp+?= =?us-ascii?Q?3id1VTMK1CunYy5ZnXvytgHSdjNjYG2O8VeMkYfPFgMEV+z5fzzwQfOwNAf7?= =?us-ascii?Q?SZp58oOXWpNdkYfkRsiHnU96flFJMtbFT2Y//4Xf8sT4wBCz8NhnBEelLct6?= =?us-ascii?Q?NAA+wrwtaJ9kuCZjeJA14YJIzXrjGX1LJs7Uiij0?= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3591CF89AAAEEC190D0F9D6FB6CC9BYAPR11MB3591namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3591.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cbc62a82-badb-40aa-8015-08db00638284 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2023 12:39:19.4228 (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: eBlGoGsPDTjZ4mlfyTSdiEmzyeSwYkv4eXNNIleji0eX5VUTTmFsgTaaViJCfe27 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB7182 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.227.249, xfe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-pubsub-10 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2023 12:39:27 -0000 --_000_BYAPR11MB3591CF89AAAEEC190D0F9D6FB6CC9BYAPR11MB3591namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, Thanks for the review! Your recommendations are noted, and they will be app= lied to the next iteration. Thanks! Alberto From: Mike McBride via Datatracker Date: Tuesday, January 24, 2023 at 5:57 AM To: rtg-dir@ietf.org Cc: draft-ietf-lisp-pubsub.all@ietf.org , last-call@ietf.org , lisp@ietf.org Subject: Rtgdir last call review of draft-ietf-lisp-pubsub-10 Reviewer: Mike McBride Review result: Has Nits These are my recommendations: Section 4: Change this: xTR-ID bit (I-bit): This bit is set to 1 to indicate that a 128 bit xTR-ID and a 64-bit Site-ID fields are present at the end of the Map-Request message. To this: xTR-ID bit (I-bit): This bit is set to 1 to indicate that 128 bit xTR-ID and 64-bit Site-ID fields are present at the end of the Map-Request message. Change this: If the I-bit is set but the Site-ID and/or xTR-ID are not included, a receiver can detect the error because after processing that last EID-record, there are no bytes left from processing the message. To this: If the I-bit is set, but the Site-ID and/or xTR-ID are not included, a receiver can detect the error because, after processing that last EID-record, there are no bytes left from processing the message. Section 5: Change this: The xTR subscribes for changes for a given EID-Prefix by sending a Map-Request to the Mapping System with the N-bit set on the EID-Record To this: The xTR subscribes for changes, to a given EID-Prefix, by sending a Map-Request to the Mapping System with the N-bit set on the EID-Record Change this: The xTR processes this Map-Notify as described in Section 5.7 of [RFC9301] with the following considerations. The xTR MUST use the Map-Notify to populate its Map-Cache with the returned EID-Prefix and RLOC-set. To this: I'm expecting a ":" after considerations and then a list of those considerations, but just see a new sentence. Perhaps make it one sentenc= e: The xTR processes this Map-Notify, as described in Section 5.7 of [RFC93= 01], and MUST use the Map-Notify to populate its Map-Cache with the returned EID-Prefix and RLOC-set. Change this: The following specifies the procedure to remove a subscription. To this: I'm expecting a ":" after subscription. Perhaps either add the ":" or re= move the sentence. Section 6: Change this: The complete mechanism works as follows. To this: I'm expecting a ":" after follows. Either add the ":" or remove the sent= ence. Change this: The xTR processes the received Map-Notify as specified in Section 5.7 of [RFC9301], with the following considerations. To this: I'm expecting a ":" after considerations. Either add the ":" or remove t= he sentence. Section 7.1: Change this: Since Map-Notifies from the Map-Server to the ITR need to be... To this: Since Map-Notifies from the Map-Server to the ITR needs to be... Change this: Otherwise, if the Map-Server has to reply with a Map-Notify (e.g. due to subscription accepted) to a received Map-Request, the following extra steps take place. To this: ...extra steps take place: Change this: Note that if the Map-Server replies with a Map-Notify, none of the regular LISP-SEC steps regarding Map-Reply described in Section 5.7 of [RFC9303] takes place) To this: Note that if the Map-Server replies with a Map-Notify, none of the regular LISP-SEC steps regarding Map-Reply, described in Section 5.7 of [RFC9303], takes place. Section 8.2: Change this: Section 8.1 of [RFC9301] suggests two TTL values for Negative Map- Replies, To this: Section 8.1 of [RFC9301] suggests two TTL values for Negative Map- Replies: Section 8.3: Change this: Deployment experience reveals that data-driven SMRs and PubSub mechanism= s complement each other well and combined provide a fast and resilient network infrastructure in the presence of mobility events. To this: Deployment experience reveals that data-driven SMRs and PubSub mechanism= s complement each other and provide a fast and resilient network infrastructure in the presence of mobility events. Change this: Concretely, in scenarios with significant traffic coming from outside of the LISP network, the experience showed that enabling PubSub in the border routers, significantly improves mobility latency overall, even if edge xTRs do not implement PubSub and traffic exchanged between EID-Prefixes at the edge xTRs still converges based on data- driven events and SMR-triggered updates. To this: In scenarios with significant traffic coming from outside of the LISP network, the experience showed that enabling PubSub in the border routers significantly improves mobility latency overall. Even if edge xTRs do not implement PubSub, and traffic is exchanged between EID-Prefixes at the edge, xTRs still converge based on data- driven events and SMR-triggered updates. Section 8.5: Change this: Interestingly, with PubSub at least the Map-Cache is updated with the correct RLOC information, even when it is not being used or waiting to expire, which helps debugging. To this: With PubSub, the Map-Cache is updated with the correct RLOC information, even when it is not being used or waiting to expire, and this helps with debugging. --_000_BYAPR11MB3591CF89AAAEEC190D0F9D6FB6CC9BYAPR11MB3591namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi M= ike,

 

Than= ks for the review! Your recommendations are noted, and they will be applied= to the next iteration.

 

Than= ks!

Albe= rto

 

From: Mike McBride via Datatracker <noreply= @ietf.org>
Date: Tuesday, January 24, 2023 at 5:57 AM
To: rtg-dir@ietf.org <rtg-dir@ietf.org>
Cc: draft-ietf-lisp-pubsub.all@ietf.org <draft-ietf-lisp-pubsub.a= ll@ietf.org>, last-call@ietf.org <last-call@ietf.org>, lisp@ietf.o= rg <lisp@ietf.org>
Subject: Rtgdir last call review of draft-ietf-lisp-pubsub-10

Reviewer: Mike McBride
Review result: Has Nits

These are my recommendations:

Section 4:

Change this:
      xTR-ID bit (I-bit): This bit is set to 1 to = indicate that a 128
      bit xTR-ID and a 64-bit Site-ID fields are p= resent at the end of
      the Map-Request message.
To this:
      xTR-ID bit (I-bit): This bit is set to 1 to = indicate that 128
      bit xTR-ID and 64-bit Site-ID fields are pre= sent at the end of
      the Map-Request message.

Change this:
      If the I-bit is set but the Site-ID and/or       xTR-ID are not included, a receiver can dete= ct the error because
      after processing that last EID-record, there= are no bytes left
      from processing the message.
To this:
      If the I-bit is set, but the Site-ID and/or<= br>       xTR-ID are not included, a receiver can dete= ct the error because,
      after processing that last EID-record, there= are no bytes left
      from processing the message.

Section 5:

Change this:
   The xTR subscribes for changes for a given EID-Prefix by sendi= ng a
   Map-Request to the Mapping System with the N-bit set on the EI= D-Record
To this:
   The xTR subscribes for changes, to a given EID-Prefix, by send= ing a
   Map-Request to the Mapping System with the N-bit set on the EI= D-Record

Change this:
   The xTR processes this Map-Notify as described in
   Section 5.7 of [RFC9301] with the following considerations.&nb= sp; The xTR
   MUST use the Map-Notify to populate its Map-Cache with the ret= urned
   EID-Prefix and RLOC-set.
To this:
   I'm expecting a ":" after considerations and then a = list of those
   considerations, but just see a new sentence. Perhaps make it o= ne sentence:
   The xTR processes this Map-Notify, as described in Section 5.7= of [RFC9301],
   and MUST use the Map-Notify to populate its Map-Cache with the= returned
   EID-Prefix and RLOC-set.

Change this:
   The following specifies the procedure to remove a subscription= .
To this:
   I'm expecting a ":" after subscription. Perhaps eith= er add the ":" or remove
   the sentence.

Section 6:

Change this:
   The complete mechanism works as follows.
To this:
   I'm expecting a ":" after follows. Either add the &q= uot;:" or remove the sentence.

Change this:
   The xTR processes the received Map-Notify as specified in Sect= ion 5.7
   of [RFC9301], with the following considerations.
To this:
   I'm expecting a ":" after considerations. Either add= the ":" or remove the
   sentence.

Section 7.1:

Change this:
   Since Map-Notifies from the Map-Server to the ITR need to be..= .
To this:
   Since Map-Notifies from the Map-Server to the ITR needs to be.= ..

Change this:
   Otherwise, if the Map-Server has to reply with a Map-Notify (e= .g. due
   to subscription accepted) to a received Map-Request, the follo= wing
   extra steps take place.
To this:
   ...extra steps take place:

Change this:
   Note that if the Map-Server replies with a Map-Notify, none of= the
   regular LISP-SEC steps regarding Map-Reply described in Sectio= n 5.7
   of [RFC9303] takes place)
To this:
   Note that if the Map-Server replies with a Map-Notify, none of= the
   regular LISP-SEC steps regarding Map-Reply, described in Secti= on 5.7
   of [RFC9303], takes place.

Section 8.2:

Change this:
   Section 8.1 of [RFC9301] suggests two TTL values for Negative = Map-
   Replies,
To this:
   Section 8.1 of [RFC9301] suggests two TTL values for Negative = Map-
   Replies:

Section 8.3:

Change this:
   Deployment experience reveals that data-driven SMRs and PubSub= mechanisms
   complement each other well and combined provide a fast and res= ilient
   network infrastructure in the presence of mobility events.
To this:
   Deployment experience reveals that data-driven SMRs and PubSub= mechanisms
   complement each other and provide a fast and resilient
   network infrastructure in the presence of mobility events.

Change this:
   Concretely, in scenarios with significant traffic coming from = outside
   of the LISP network, the experience showed that enabling PubSu= b in
   the border routers, significantly improves mobility latency ov= erall,
   even if edge xTRs do not implement PubSub and traffic exchange= d
   between EID-Prefixes at the edge xTRs still converges based on= data-
   driven events and SMR-triggered updates.
To this:
   In scenarios with significant traffic coming from outside
   of the LISP network, the experience showed that enabling PubSu= b in
   the border routers significantly improves mobility latency ove= rall.
   Even if edge xTRs do not implement PubSub, and traffic is exch= anged
   between EID-Prefixes at the edge, xTRs still converge based on= data-
   driven events and SMR-triggered updates.

Section 8.5:

Change this:
   Interestingly, with PubSub at least the Map-Cache is updated w= ith the
   correct RLOC information, even when it is not being used or wa= iting to
   expire, which helps debugging.
To this:
   With PubSub, the Map-Cache is updated with the correct RLOC    information, even when it is not being used or waiting to expi= re,
   and this helps with debugging.


--_000_BYAPR11MB3591CF89AAAEEC190D0F9D6FB6CC9BYAPR11MB3591namp_--