Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 09 April 2021 04:21 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDC63A2B14; Thu, 8 Apr 2021 21:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.617
X-Spam-Level:
X-Spam-Status: No, score=-9.617 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=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=Hg9MpDem; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W5G+XDSc
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 Equ5_i_hKkoa; Thu, 8 Apr 2021 21:21:13 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947693A2B12; Thu, 8 Apr 2021 21:21:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10809; q=dns/txt; s=iport; t=1617942073; x=1619151673; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qHvwStnkNix5AP84zyq0v9MPf9VsP4w+sM7/dG4Rnvw=; b=Hg9MpDemU5RGHLIhTjAENHp0tHKYhUHF60evoSSqnoQWhpXkJ7/cYffj xBG+bgEME46KZKRclGwBQ+sCN287fpjA83k599MYARCNytaGL/0H++pIB kqn0B8klXXjIqtotY7A39CnqAqVgrJ/A5HGYQ7/FLuSQNGDLZzGwDznYA M=;
X-IPAS-Result: A0CiAACS1W9gmJFdJa1aDg0BAQEBAQEBAQUBAQESAQEBAwMBAQFAgVKBUyMuflo2MQqIAAOFOYhTA4ouhHmKFIFCgREDVAsBAQENAQEdCwoCBAEBgRYBgzkCgXcCJTgTAgMBAQEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBaIVQDYZEAQEBAQIBAQE4BgEBKwEGBQEEBwQCAQgRBAEBAR4FCyEGCx0IAgQOBQiCaQGCVQMOIQEOn3sCih91gTSBAYIEAQEGgUdBgxkNC4ITAwaBOYJ2ilcnHIFJQoETQ4FfgQA+gh5CAQEBAQGBKAESASMwgxqCK4FYAWsIPB0JBCIZFgICIC4LPRwlBCQRGZELEoJyAYhdjEaQTQkwWwqDC4ljhx2GRIVbg02KeJNQglyXJYlagxaPRAMBhGECBAIEBQIOAQEGgWsha1gRB3AVO4JpUBcCDo4fGR6DOYUUhQRBcwI2AgYKAQEDCXyLBgExXQEB
IronPort-PHdr: A9a23:fkmKbRY3a53+QNLN7PqnXob/LTDBhN3EVjU944c7i79IbqWo9ojjO 0qa//h2kVvVRu3z7vNYzefarvOoVW8B5MOHt3YPONxJWgQegMob1wonHIaeCEL9IfKrCk5yH MlLWFJ/uX3uN09TFZX7ZkGUr3GvvnYeHxzlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8N hKz+A7QrcIRx4BlL/VZ9w==
IronPort-HdrOrdr: A9a23:eTIcMKr2DkiBrX3vQKQJGZcaV5taK9V00zAX/kB9WHVpW+SivY SHgOkb2RjoiDwYRXEnnpS6NLOdRG7HnKQV3aA4Bp3neAX9omOnIMVZ7YXkyyD9ACGWzIBg/I 9aWexFBNX0ZGIUse/T6gO1Cstl5dGB/ryhi+u29QYTcShBQchbnmBEIyycFVB7QxQDIJI/Go aV6MYvnUvfRV08aMOnCn4ZG9XZr9rQm578JTIADRgr6A6B5AnYqYLSOR6ewxsYTndz0a4vmF K13TDRy4eCl7WAyhHa33LO9Jg+orvc4/ZKGcDksLlvFhzCkQCtDb4RPoGqnDdwm+237UZvrd +kmWZdA+1Wy1f8Ol64ugHs3Q6I6kdv11bHxUWDiXXu5ezVLQhKcfZpvo5SfhvH50dIhrgVu8 gnsxP7xvhqJCjNkyjn69/DWwsCrDvInVMZjeURg3ZDOLFuDoN5kI0F8EtZVLcGES7qgbpXaN VGMcDG6P5aNW6ddnDS11MfueCEY3JbJGbjfmEy/uiulxRGlnFwyEUVgOYFmG0byZ47Q55Yo8 zZL6VBjth1P4wrRJM4IN1Ebdq8C2TLTx6JGnmVO07bGKYOPG+Ig4Lr4Y8y+PqhdPUzvdkPsa WEdGkdmX85ekroB8HL9oZM6ArxTGK0Wimo7c1C+Z5juPnZSKDwOSOODHAi+vHQ5sk3M4n+Yb KeKZhWC/jsIS/FAoBSxTDzXJFUND0QS8sQttEnW0+fo87CJ4Hw39arN8r7Ff7IK3IJS2n/Cn wMUHzYP8Nb9H2mXXf+nVzQVhrWCwrC1KM1NJKf0/kYyYALOIEJmBMSk06F6saCLiAHtqQ3eU B5Ma72i6/TnxjuwU/4q0FSfjZNBEdc57vtF1lQoxURDk/yebEf/9OFeW5T23ODLgRlT9zfFR Neo1gfw9PyE7WggQQZT/63OGOTiHUe4FiQSY0Hp6GF7cD5Po8jAo0+Q6x3HwXTHxlzkQJnwV 0zMDMsdwv6LHfDmK+lhJsbCKXjbNF6mh6sOtMRg2nYr1+gqcYmQWY7UzaiXdWMuxsnQyNZiz RKgvQiqYvFvQzqCGMkxMwkLVVHaQ2sccN7JTXAQL8Rp5fGV0VbS3yQiTmTlhcpE1Cah3k6ty jGNi2befbCH1xHnGtXu5yaqm9cRyG6Y196bGx8vMlbE2nL00wDjdOjV+6Uz3abbEcEz6UmFA z9JREWIg9o2rmMpUOosT6fCHQrwYgvNOTBDLIlN6rewG+pNZfgr9B0I9ZEuJliL9zgqekNTK aWfBKUNirxD6cz1xWSvWtNAlg4lFA01ffp0gbi9m62wTo2BufTOk1vQ9ggUpqhxnmhQ/aDy5 Nii90p+eO2L2Xqc9aDjaXadSRKJB+WoWm4SYgT2NpplLN3sLt4BJ/AVzTUkHlBwRUlNc/x0F oEX74T2sG2BqZ/O8gJPy5J9Fsgk9qCaEMtrwztG+c7OVUglWXSMd+F66fBwIBfTnGptU/1Ix 2S4idd9/DKU2+Y2bkWB7k5LG5WZEI/gU4StN+qZsnVEkGnZutD9F21Pjuha7dbUrGCAqhVoR Bg4d2E9tXnOBbQyUTVp398La1P+Wr8Hp/3DwKIBOJS89u1fV6LmbCn5cavjDHxDTu3An5o8b FtZAgVdIBEjDJnkYg8li61Qabzqlg+k1Rf7Sp8/2Sdk7SO8SPeBwVeLQbdgp9KRjFdPXiDkN Td/YGjpQHAySkA3YOGCVxZcd5PEcUBV4T7Ly9hLs4Lob6jlpBf9RhrcVMpFG4ziDf0wuNg0/ O4wZzpKp/fNUs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,208,1613433600"; d="scan'208";a="694575282"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2021 04:21:12 +0000
Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 1394LB3g014729 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 9 Apr 2021 04:21:12 GMT
Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 8 Apr 2021 23:21:05 -0500
Received: from xfe-rcd-001.cisco.com (173.37.227.249) 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.3; Thu, 8 Apr 2021 23:21:05 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) 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.792.3 via Frontend Transport; Thu, 8 Apr 2021 23:21:04 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QkqmnwCyHqwEtUOKWOuNsw1YjOzBNDpj17SfxcMeRJ675uWnlFpXyEmYtV+q9ZD4y3PxpvM/DxUUPVYVjTr+ITzylkr+5NjP1fFgmRWBOlRBBKGhNgEB9GGvWfpSGYLdR6XQRLJ2VyfFWkbiLMsjMdSyEEAudoXdiliNRiQLyTJAb/4XrHbRXfNVv0adJvLu4jE21iFmdoHdj74XESYwOiR+Y3hIQM4iJFyfxpbndawa1XlErarf3R99jkm483i80yXfhXaPKVJjCt73srPD255BwGz5VYwYZxjsTqMQxLtHmomgYs1lTYl9ANKopfWF6qjm3eYieIZoNTgK29xv6w==
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=5PPjwQSTxcTP+wPj1SUpCBham2SV+AlNlWtkTu9xk+U=; b=PGHtk95ur530g9RS0ysOCn4xBvYsH4RTMWCTfjYK+xV225SZFo+2nx2Fo80I/Son3khv1mLXb3lZQbkBlRwIrZ+gtNksGNRIRQ79RODvkOb8rR93BAU7jGRX9zJAqxTlZXCWikWkl3gEZJBiShES5Y0ugWZVpBRW1VsBk0vazfuFLOLUlzAiWKo5IvQ/vVKmwk7Pkn7r9dwMye45dYzxAVsmip85pc4j5Vir6uoMxBmWATT1ZGcuhD/RqtbQ6WDYmeo782WoF4tIPCtRsqy+btrvV2CPh4d/tvliKMwkRP9SK34mne6XC/NbmitL/PZC5Dmza9H2aZooGLfbr0hkNg==
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=5PPjwQSTxcTP+wPj1SUpCBham2SV+AlNlWtkTu9xk+U=; b=W5G+XDSc3a9xNU9ucA2iDkle9G32mqp8qXA9Rd+O2CUu7xQzV8tQ3YVDfQycWXtreAuL5P0120JXkVOse8CMs3tLBs6BjNljLA79xUGHbX+cL4gwpfSBwoHtPFU82hSbn+LxKklCQLCNLKVHRFO3zAerViLke7sMb7ksDc33ogM=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2368.namprd11.prod.outlook.com (2603:10b6:300:7a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.27; Fri, 9 Apr 2021 04:21:02 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::592f:2e19:cf5b:a0f5]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::592f:2e19:cf5b:a0f5%5]) with mapi id 15.20.4020.021; Fri, 9 Apr 2021 04:21:02 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "draft-ietf-lsr-ospf-prefix-originator@ietf.org" <draft-ietf-lsr-ospf-prefix-originator@ietf.org>, "chopps@chopps.org" <chopps@chopps.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)
Thread-Index: AQHXK3RwlojH1/uVU0SQkMY7XGkQY6qosgNAgAJokgCAAHpiEA==
Date: Fri, 09 Apr 2021 04:21:02 +0000
Message-ID: <MW3PR11MB4570BA966A835B375198A976C1739@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <161777569111.16216.18390599109395230994@ietfa.amsl.com> <MW3PR11MB45702CDA1976A9A65D26A41FC1759@MW3PR11MB4570.namprd11.prod.outlook.com> <20210408205002.GV79563@kduck.mit.edu>
In-Reply-To: <20210408205002.GV79563@kduck.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2e8ed5c1-d8dc-4f00-3394-08d8fb0ee2c8
x-ms-traffictypediagnostic: MWHPR1101MB2368:
x-microsoft-antispam-prvs: <MWHPR1101MB2368D55C7097B427DA438EB5C1739@MWHPR1101MB2368.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PMK18XQKOziLp49jo+arQVEKzePA88pl3oIRI9TroyrIzMY1Z4zfG90/B2kPzTxg97qZMHwbugzJcMJm3RzN8LaTZkOwoMwQzvgDdgdbTto6Pfgg41b4C9BtVVR7bQCa/Wg0LAaYJ4usP/Sgekw0tglpVHHuNvHNRZTtQwTmeJUz2mXRy9tLg5P54765RWoe/dkgUlrIBxL0mygyrhjGdXMXONnxuTjKzhWs7zs/2r9JcoAvFcPoNCHKZOz1PxJKub0Ob+dwkNIRXNZQyaUKL2Ztu6GKLiKz89CaCt+2ktJEC8JzmZvLQ8cdZlNdGOItSSCC+i2vldQiF5+LTRcg1HW9UQlbJInQvT66wDA8roxYl5uqI+67A5eNqnBGtHe0xtQgr9r8D35ktJ47zLJiNPWkjA32VfN7R073N1NwRZGGF28lKeGWRGASykyT8WtoGWyNThgN8R7y4VVDDgDIUBFKE2hfS0/FvgXax0B8wGr3LC79c9IpOLGDk+4xyP30pNgv73QY36pjXjdjPq/jeorCkxGQGqJiEgcuvpDSowz1BJQKuyFdghHVWm43hZVOc4ewuweEdtg1sFZP7CnwLVlXzuvy1SbgFMFMtwnzifZ/KNAikY00vc1riNF90xXMUZrkZAniSJwKm7UgRSfxKudDfnjMUuEIJspRzPhlkuNQ9yuj7d2+k1xA4S8cIwcEUPdFlShwhX9VyU41QsW1OGTXi+38e7eRxvVHM+v0Oq4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(376002)(136003)(366004)(396003)(33656002)(6506007)(7696005)(478600001)(66946007)(66476007)(64756008)(30864003)(55016002)(76116006)(26005)(53546011)(316002)(86362001)(6916009)(186003)(966005)(4326008)(83380400001)(71200400001)(54906003)(38100700001)(52536014)(8936002)(2906002)(66574015)(8676002)(66446008)(5660300002)(66556008)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: fP6hEHKUPi9hs+TMwXbf6zPKSoyuevBw0NiQuyKcKlenjiFoepq6I/sM04Ci1rjm28WG/UkbzOSb5+Ly+ygB/nW6Kn+8+1fc80nFAUbfZK8vdjAQ+wuAvAjnH1n6vi3dNpRivDqR8W08dXSxfcHJ0LQ+AOVWL0xfPyhIsWjqeUfkyRdJuAoGnosWkYg5TeewJU7ZtgD/WpENmJAirG3mnSfa4iFVpiUUgN5tsCcqmf/GeWxAed8aIhXQlHqIrja+ZKhLh0WDGyb3YwCHu2rZ7MdldPVuM8YWSRdJNQOWlgUk3z5x2NmF0h0L7ifiz+oSrYO4QPor8iYornvkxX3DoFTAP9BePvmJhhjOp6ZBCDzhE5xVMjQoOWdO4ty8K3qPNdPEFp9M2ldwGo145m7KHvwBZb0t7bRQhfDp2XXFR+836t7vfkB2u6EOcrG056SYzRZxXI7+rzmg72QfjCt1Ydt7nrtdQMePY89yq/GbKxlY8HBIv2llgIz58SZiF63fTCxsJ1Wz3AjpGV+lH1P5lvcQpiyWh70l5H3EEg3/yBPn+etVMWrRnZn8l0hcWDyFWeRDB04cKVS17+79GnVk1z2BM+IhohqrNdzNqnChPSDivGz2FeMY8GT2KWWP8khx3L8NeI4csefD5WoVa1V03dbgjsCH0cbLlXWoXOLjazn3NzKNA6oPtDWfElbkOIsexiENQW31UMCCFsHQVIV2pqhsaHv8ItjSawz8Myh2GDVHrasXDD5fL0WqcQF5T+DIcQY6lTC/CZ6AxI1f1O8vexIz4TRFHfg/HNX2i0RmrpqP45oAra2ZysgJ5wHyoVROeOBYibu7PS2VcyFAcRp4b3c9Nv8AnhaK9ujAGGoV5iOlV/cHjqLf5AMbtM8hbx89HipcoZHobEOHvFSK8287rCLwHsfUlKyx9RCti4e9lJuMogaKX+kU2993FmNZp0icZycyuXboQPP66Rp0haKkJ1tM0hHmVZx+ViqQodrFwBhsMha0NxgfSD8xBjQCSRlG/lEmAO4cHm1YRDRX24zMlZGzjSXA6gn1PsalTgYeO1J/XxIEQ0oMMJju/rKhS2FxbpbsdwOTZ2o0Fkl85qJ8efQGP8otri4oxa6cYnDzHgu/t6LkTo8ekdVqSA4LDQlsPVCCiaQbH4imFOXwrhZDXSlg6em5wf567KENwt3NeFymIOKxNC7Ianot8jShTvDxnbtK/U4WUeO8XaTFkPGZEDlNJboddeMevNr0MIkKyXwUmPqbH2ywmbF8I9+AruBCo1ImeiCFiu1yYkXg3+JAtuZgSDHBSyQUcJqV+UlOXKBFW7yTSj+deS0h4zk6ZZop
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e8ed5c1-d8dc-4f00-3394-08d8fb0ee2c8
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2021 04:21:02.5551 (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: PR5iXJOIwKp95EavtKVs7RSUrDLyzeWZz3PNhboUMhR2T/n1rbDWu1a/ynlwceW3G6iWAulYD6FknAXDQjUGKA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2368
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/reCFqQBW3ZOr_Ei9dGXXXIpirpA>
Subject: Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2021 04:21:18 -0000

Hi Ben,

Thanks again for your review and comments. I will post the (final ?) update EOD Fri India time in case there are any other inputs.

Please check inline below.

-----Original Message-----
From: Benjamin Kaduk <kaduk@mit.edu> 
Sent: 09 April 2021 02:20
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: The IESG <iesg@ietf.org>; lsr-chairs@ietf.org; aretana.ietf@gmail.com; draft-ietf-lsr-ospf-prefix-originator@ietf.org; chopps@chopps.org; lsr@ietf.org
Subject: Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)

Hi Ketan,

Thanks for the responses and updates; I just make a few notes inline.

On Wed, Apr 07, 2021 at 08:44:42AM +0000, Ketan Talaulikar (ketant) wrote:
> Hi Ben,
> 
> Thanks for your review.
> 
> An update to the draft with to address some of yours, John's and 
> Eric's comments has just been posted : 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-origi
> nator-11
> 
> Please check inline below for responses.
> 
> -----Original Message-----
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Benjamin Kaduk via 
> Datatracker
> Sent: 07 April 2021 11:38
> To: The IESG <iesg@ietf.org>
> Cc: lsr-chairs@ietf.org; aretana.ietf@gmail.com; 
> draft-ietf-lsr-ospf-prefix-originator@ietf.org; chopps@chopps.org; 
> lsr@ietf.org
> Subject: [Lsr] Benjamin Kaduk's No Objection on 
> draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lsr-ospf-prefix-originator-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator
> /
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In the ECMP case is there a way to correlate (order of appearance?) the listed router-IDs with the listed reachable addresses?
> [KT] No.
> 
> Are there cases where you might choose to only advertise one but not the other of the prefix source Router-ID and address?
> [KT] Normally no. However, there is some text in Sec 5 about policies that may be employed to abstract/hide information (e.g. across areas/ASes) - such mechanisms may be used, as necessary, in a deployment.
> 
> Section 2.1
> 
>    The parent TLV of a prefix advertisement MAY include more than one
>    Prefix Source OSPF Router-ID sub-TLV, one corresponding to each of
>    the Equal-Cost Multi-Path (ECMP) nodes that originated the given
>    prefix.
> 
> Is there any subtlety (or complexity, I guess) to how the advertising node knows about the other ECMP nodes advertising the same prefix?  
> [KT] An ABR performs the inter-area prefix advertisements based on its local route computation (i.e. the sources contributing to its local intra-area route). It is not affected by the advertisement of the same prefix by another "peer/pair" ABR. I hope I've got your question right though.

I think you answerd a slightly different question than I intended (but it is still an interesting answer to hear).
In light of your explanation, I think my intended question degenerates into "are there any subtleties with how the node performs its local route computation", which probably gets an answer of "yes" but is clearly out of scope for this document.
[KT] You are correct.

> For example, would there be some transient discovery stage when first setting up the ECMP advertisement and only a subset of the ECMP nodes are actually listed in some advertisements that go out?
> [KT] Taking the scenario of the previous response, the inclusion of ECMP origin node information would depend on how the ABR router receives the intra-area prefix advertisements via LSAs from the nodes owning that prefix, how they get processed by the SPF computation and then how they get included in the inter-area route advertisements that the ABR generates. There are various timers and scheduling mechanisms in the protocol for each of these steps - but I would not call these timers/back-off mechanisms as "discovery".

I think by "discovery" I was thinking of a scenario where a router does a cold boot and has no local RIB at all -- will it advertise anything
(incomplete) while it is still learning routes, and will such incomplete advertisements cause issues when processed by its peers?  But I think your
(collective) exchanges with John about how the system is inherently dynamic make me realize that this scenario is not particularly noteworthy, and is unlikely to cause significante issues.
[KT] Correct. There are widely prevalent techniques or best-practices for handling such cold boot scenarios - i.e. to allow the node to stabilize before it starts handling transit traffic [RFC6987][RFC8770]. However, they are orthogonal to this specification and not within its scope.

> Section 3
> 
>    another non-backbone area.  The ABR performs its prefix calculation
>    to determine the set of nodes that contribute to the best prefix
>    reachability.  It MUST use the prefix originator information only
>    from this set of nodes.  The ABR MUST NOT include the Prefix Source
>    OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it
>    is unable to determine the information of the best originating node.
> 
> I feel like this text might be hiding some subtlety as to the nature of determining the "nodes that contribute to the best prefix reachability"
> -- is this a concept that is well established in the core OSPF RFCs already (and thus doesn't need further explanation)?
> [KT] Yes, it is a well-established part of the OSPF protocol/implementations.
> 
> Section 4
> 
> We often consider privacy considerations as part of the security considerations section.  Since routers are to some extent inherently "well known", they themselves may not have much privacy considerations but there may be something to say about propagating additional information about the internal structure of a given network.  My understanding is that OSPF areas are all under a common administrative domain, so this mostly only seems relevant to the case of AS-external advertisement.  One potential consideration would be if there is value in hiding that a set of prefixes are all advertised by the same router (the "linkability" of the prefixes, if you well).
> (Hmm, I guess this is somewhat related to the existing operational 
> considerations discussion, but not entirely equivalent.) [KT] Yes, it is related. Hence the text in Sec 5 to cover the scenarios where there may be a desire to hide/abstract a set of prefixes' origin info while allowing for other prefixes.
> 
> If we go into more detail on potential use cases, we might accordingly be able to go into more detail on the consequences of a rouge node injecting incorrect prefix source information.
> [KT] We are focusing on the OSPF protocol specification here. The details of the use-cases are beyond the scope of this document.
> 
> Section 5
> 
>    protocol.  Based on deployment design and requirements, a subset of
>    prefixes may be identified for which the propagation of the
>    originating node information across area boundaries is disabled at
>    the ABRs.
> 
> Per my previous comment, is this even more important at ASBRs than ABRs?
> [KT] Ack. I will update this in the text.
> 
> NITS
> 
> Section 1
> 
>    The identification of the originating router for a prefix in OSPF
>    varies by the type of the prefix and is currently not always
>    possible.  [...]
> 
> (nit) my intuition is suggesting that the intent is that the "procedures for identification" vary and are not always possible; is that correct?
> (It seems to me that "the identification of the originating router 
> varies by the type of prefix" would indicate that the actual identifier used for even the same advertising router will be different for the different type of prefix being advertised, which doesn't seem to be what the subsequent discussion describes.) [KT] The procedures are actually described in the further sentences of the paragraph. It also explains the cases where this is not possible.

I do see the procedures described later; this was just a note about the grammar of this sentence -- I think s/identification/procedures for identification/ would make the grammatical types match up better.
[KT] Ack - Rewording as " The procedures for identification of the originating router for a prefix in OSPF vary by the type of the prefix and, currently, it is not always possible to produce an accurate result."

Thanks,
Ketan

Thanks,

Ben

>    address for the router.  The IPv4/IPv6 Router Address as defined in
>    [RFC3630] and [RFC5329] for OSPFv2 and OSPFv3 respectively provide an
>    address to reach that router.
> 
> (nit) Is it useful to indicate that these are TLVs, here?
> [KT] The IPv4/IPv6 Router Address is in fact the name of the TLVs in the referenced drafts.
> 
>    the core OSPF route computation functionality.  They provide useful
>    information for topology analysis and traffic engineering, especially
>    on a controller when this information is advertised as an attribute
>    of the prefixes via mechanisms such as Border Gateway Protocol Link-
>    State (BGP-LS) [RFC7752] [I-D.ietf-idr-bgp-ls-segment-routing-ext].
> 
> The draft-ietf-idr-bgp-ls-segment-routing-ext reference seems rather unmotivated by the current prose leading up to it.
> [KT] It is an informational reference that explains how the information is provided to an external controller or application via BGP-LS.
> 
>   Per John's Discuss some further exposition on the expected use case might help.
> [KT] As mentioned in my response to John's Discuss, the further detailed discussion on use cases are beyond the scope of this document.
> 
> Thanks,
> Ketan
> 
> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr