Re: [Idr] Rtgdir early review of draft-ietf-idr-bgpls-srv6-ext-07

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Tue, 08 June 2021 19:14 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9943A3A74; Tue, 8 Jun 2021 12:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.596
X-Spam-Level:
X-Spam-Status: No, score=-9.596 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=D1zXYn3F; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=o0UwCQ53
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 qINxlzdAnDOt; Tue, 8 Jun 2021 12:14:23 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6E83A3A6B; Tue, 8 Jun 2021 12:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24600; q=dns/txt; s=iport; t=1623179663; x=1624389263; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rndtHTTOSXYFpyn9wlv2KvGqpR04UJ/lYOU6W8iomQM=; b=D1zXYn3FzFhVjdQYaopWUJRG4bjLAgk3w6yh03+xjESNEf+ZalIT5Ozb sidUYOl/T7bA0zHAofpHrjxh14JnK8b//dkVl3z9dHs72RS5CCEZQ0UKN Et6GuIPyas4KofYsh4u/LwE4BSGr/hTghyG4PdqlYElj7mPdxc9JPxT2h Q=;
IronPort-PHdr: =?us-ascii?q?A9a23=3ABdME5xCF3QCmHKIdyeVbUyQVjBdPi9zP1kY97?= =?us-ascii?q?Z4rh7VBNK+kuYnhbwTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pN?= =?us-ascii?q?VcFhMwakhZmDJuDDkv2f/nuYyA9E4JJUxl4/CLzPU1cAs2rYVrUrzW75iITH?= =?us-ascii?q?ROqMw1zK6z1F4fegt7x2fq1/sjYYh5Dg3y2ZrYhRCg=3D?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A6+1Bt6h3V0wntd92+O9Hhwcw4HBQX2Z13D?= =?us-ascii?q?Abv31ZSRFFG/FwyPrOoB1L73HJYWgqN03IwerwR5VpQRvnhPlICPoqTMmftW?= =?us-ascii?q?7dySuVxeBZnMrfKljbexEWmdQtrpuIH5IObeEYSGIK8foSgzPIUOrIouP3ip?= =?us-ascii?q?xA7N22pxwGIG0aCNAD0+46MHfnLqQcfnghOXNNLuvl2iMxnUvYRZ14VLXeOl?= =?us-ascii?q?A1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPUf2FmAtza8yr?= =?us-ascii?q?Sosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcFcsvy5zXQISdOUmR?= =?us-ascii?q?AXeer30k4d1gNImivsl1SO0FzQMs/boW0TAjHZuAWlaDDY0L3ErXoBerp8bM?= =?us-ascii?q?RiA0bkA45KhqAi7EqNtFjp66a/RCmw7xjV9pzGUQpnmVGzpmdnmekPj2ZHWY?= =?us-ascii?q?9bc7NJq5cDlXklXavoMRiKo7zPKtMeRv00JcwmB2+yfjTcpC1i0dasVnM8El?= =?us-ascii?q?OPRVUDoNWc13xTkGpix0UVycQDljNYnahNBKVs9qDBKOBlhbtORsgZYeZ0A/?= =?us-ascii?q?oAW9K+DijITQjXOGyfLFz7HOUMOm7LqZTw/LIpjdvaNKDgDKFC0KgpdWko+1?= =?us-ascii?q?LaV3ieffFm7ac7uywlGl/NKAgF4vsukKSRlIeMNobWDQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAQBlwL9g/4wNJK1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUYEAQELAYFSIy4Hd1o3MQuEPYNIA4U5iHcDj1aKQYFCgRE?= =?us-ascii?q?DVAsBAQENAQE1CgIEAQGEUAIXgWACJTcGDgIEAQEBEgEBBQEBAQIBBgRxE4V?= =?us-ascii?q?oDYZFAQEBBBIREQwBASkOAQsEAgEIEQMBAQEDAiYCAgIwFQgIAgQBDQUIDAc?= =?us-ascii?q?HglCCVQMvAQ6aYQGBOgKKH3qBMoEBggcBAQYEBIE4Ag5Bgz4YgjEJgRAqAYJ?= =?us-ascii?q?6hA6GYSccgUlEgRQBQ4JgPoJXCwEBAgGBQxwVD4JxNoIugVgBEC4UGQYCLBA?= =?us-ascii?q?mBA0iFA4BASIuIwwGDAcsFQ4CDgsBCQYMAw8JO5Bzg06MLZp/CoMchFiFN4Z?= =?us-ascii?q?ZVoZjhW4Sg16BQolehiqNW4JhlVKCGIl/kxkKBAsNAYRZAgQCBAUCDgEBBoF?= =?us-ascii?q?qJYFZcBU7gmkJRxcCDoFwjC8JAxaDToUUhUpzAjYCBgEJAQEDCXyHei2BBwG?= =?us-ascii?q?BEAEB?=
X-IronPort-AV: E=Sophos;i="5.83,259,1616457600"; d="scan'208";a="902132069"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jun 2021 19:14:21 +0000
Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 158JELic032006 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Jun 2021 19:14:21 GMT
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 8 Jun 2021 14:14:21 -0500
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 8 Jun 2021 14:14:20 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 8 Jun 2021 14:14:20 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=INIz8B2glCv+yiNRivSRiQsBkpZm2NQRsP9Xe5TCpkNHUfTLkP9xRCeKkD9byQVgnXEYqU8x7IpmjMZX3c2aYNvoeevTPYH4yBYL5sU5tQsvJR5wSamOXEFuxB4kGb47+SQJ64TkciiRE7RaAEJ9NxrP6HLnjFi4s3YhLZaltA4AbjUMmbPEFN6bF9f0wnzDaROeNE2XQs92OTF37JnD8Par6mETlPD9b5xQpPqdwNf/nQfT9CmkFN4Cyi/shuBo6XNZThiq/uZcqg5dINXbM/VRbAn6bgKMDdizzmEhN9jL2A1oiFyXA5ys69BPJPfKrITqa6cUszYLNTjMrBPN6Q==
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=rndtHTTOSXYFpyn9wlv2KvGqpR04UJ/lYOU6W8iomQM=; b=njIn6/pgJUZ33PggWYngN4XifXZyhij//qGDvzdqQvtNKbubbnfXudeTCw/ggYbD+PFBlRdHqevNE/Uom1qV1kx6UxBh/y6H/74BvVpqt72xa09kvmPIgnwP+D7kyPe6kiTnhEE5iPJAtWDArJ7UKHz8LIH69qOHfasOMErfCfX/M/MRC4b8suAK4hwztTCpbrEUC4TADcsT4cZMdoynfrFjY3pX53IAiw30iaFne6XjCnEWfNtaBYKUYbvfCHbWM0sjtgli2knW6QBEpfWy11AY2IMyS3qQ3vpPD3r3a/DlCSd/zXn341aScei9o32ejhnIIICw0JWCTtKAU/pxfg==
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=rndtHTTOSXYFpyn9wlv2KvGqpR04UJ/lYOU6W8iomQM=; b=o0UwCQ533lqei6LQgAdzVKb8vrQOUctI4XaE/USFw9zxAik+NZixhlKHTed2H/CDRxKpKLGxPMeyFpdf40yvWkKesChdsRTgUwX6RtsjySj3kIBnap7cvTkgNzo4px6nDnUcz7TGz/VvFhnsupHI0v39wHSbLSH68EC60z7NOt0=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2126.namprd11.prod.outlook.com (2603:10b6:301:50::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.29; Tue, 8 Jun 2021 19:14:19 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::ec42:2e34:fc81:d45f]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::ec42:2e34:fc81:d45f%6]) with mapi id 15.20.4195.030; Tue, 8 Jun 2021 19:14:19 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Adrian Farrel <adrian@olddog.co.uk>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
CC: "draft-ietf-idr-bgpls-srv6-ext.all@ietf.org" <draft-ietf-idr-bgpls-srv6-ext.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Rtgdir early review of draft-ietf-idr-bgpls-srv6-ext-07
Thread-Index: AQHXVNBrwCpZivHRgUqYKOXpCmUudqr9Opqg
Date: Tue, 8 Jun 2021 19:14:18 +0000
Message-ID: <MW3PR11MB45704BADF4A30DFEBA6A7B69C1379@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <162232320026.7852.16606328132879450829@ietfa.amsl.com>
In-Reply-To: <162232320026.7852.16606328132879450829@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.26]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 91e45281-b783-42b9-1ae1-08d92ab19da0
x-ms-traffictypediagnostic: MWHPR1101MB2126:
x-microsoft-antispam-prvs: <MWHPR1101MB2126715E86E5A0B94FFE614DC1379@MWHPR1101MB2126.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rgy3HwNmXSQhjR0UWj9D5AaO4EL1KWaxVTbKbSY7SZpkKC/EeJR5wZbE0n5W3Qj4Lsa9q9ZVzo1Zltw5n6ahMDGxhfTA14oByMqDZ2fTypq3SbETBenfwy6+u6QyrA5X+pEsVC04IUgQ5jIpcmepAkfIlSRUTuEmnyb87Tn+fNReLt1QFMgJI/uFoeUqitn6zxcj2lc/IHRfzeuefPGRkuGlNYJQlRHVKdOfQZRZCUrSeQsFiJFWE7/mPUK46Zb4HnznNMzmzuQk+F8+Vi4keXtd1E3n84CQgfl1E1N6XLMvUn3N81g6Qyc+F6Qpsp8OTthaBWM4UHxHDJevOxdvyx/UmFfzik42Ch/wxpTgnbOgXyy6df7m04cocDlxfuAPO4emrI8dL3BfvpcI/89/10XFNq4rkwwNVwLcufGKfBkARg+wsnq47kluCBUWaHvA0yqqUhBmnlnSSi3BFRMAlrmjCbPheF7B8GIzMDVJQW3cDzp0JeuGkOtIVR5T+dI9zryxviPT0PYt5RGDI+leX0UkhaRO36uKX3T5YhUUQPaXeXhoHBqZ51ZSTsDg10xb12bGCfYDAVSDJfHtdbKBUl3PZTTAAvXlDr/GMOAmisI5VKs6gwJNTyB2gv+S2Y+OK5xV0WNkJMxJJ5m/R3Jih5IXOcCWqIpY8utL+4V8XCeDiLTURIFMel61MTDCisHW6ETR8nTmNHsnw9fGZ39oYP85wgIJ+TpfN8Nc58kEqM5hEXlDVbBIKIscXZKCBH5U
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:(396003)(366004)(136003)(39860400002)(346002)(376002)(8936002)(9686003)(55016002)(8676002)(30864003)(5660300002)(122000001)(83380400001)(33656002)(110136005)(76116006)(54906003)(66446008)(64756008)(66946007)(4326008)(66476007)(966005)(66574015)(478600001)(2906002)(71200400001)(52536014)(53546011)(7696005)(6506007)(26005)(38100700002)(186003)(66556008)(86362001)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TTNGQ05LNHMzcDYwUnVpdXBPOHlueHg1emU0a0JpdU8wWS8wNUZuTW1ZMzBz?= =?utf-8?B?cWxmb21USnd1T1d5QVJVRUtkYVlIclMyTit0M3VJdG1HY0ZaaGM3bmhxeDB4?= =?utf-8?B?cGVZdkZRM0NoSDVlL09QVzk3Q096R29hMitod2NxaU1OUHB1MWRGZ01wSWhr?= =?utf-8?B?cGgxMnJ1Y2ZSQTRHQUlnVExYdGtJSDdGcUQ4VTJBQ2VteG9Zd3oyMmRVNWlC?= =?utf-8?B?ZklKMnBocjF0bXV4Sk5mTXp4TDZqdFEzcGJLZUd2cFdYNVdLOFBTNHQ2UWhT?= =?utf-8?B?Wjc1aDdzeGtrSGUyVU1lT2hVNHBYNkVQT2ViamV6YVRIVGZ6WW5odEhtR1dR?= =?utf-8?B?RnI2WXFTOG8rUGIrNzdxVVNlMm02MFU3Q2tjU1hITHZIVmxYNG05ajZiS3FW?= =?utf-8?B?eG51bEt3N2lwbjY4Q2FpU1d0VmxzMDhERzNXVEFZUm5vZ0VXUGFuWU5CRFNN?= =?utf-8?B?MFpwUUdEUm1pb0UvK016YjJqUTJFT2dvdUV2NVIySnBZdEhDcDl0a1pkQU43?= =?utf-8?B?MW5XT1VGU3FWTDFYY2hubHJ5OTZnZ0V0Q1NkWTF0RlIyQnNUTVBpVjdPUHc1?= =?utf-8?B?SndZYXZ3WnhuakUvYVEydlVzdVZtV1hJNEZPUDFPR2pIZHdoM1F4K0dhdTk2?= =?utf-8?B?UnFWcEZ5NFJjczF2eUZRVmc1UC9peFdSRmU5UEZqazd4SHd4MXNkU1FETlp3?= =?utf-8?B?bExiSTB0VjlpZmY4Sk5qVHpnYmkrL0hucUYrWUV5ZlIyV3d3dzR4bXFvQ0Nh?= =?utf-8?B?cm1xY1VXR1JnV0szcytWQ2FPZlhTQmk1ZHdmR3hpYlFQelZDT1loM1M2SHpv?= =?utf-8?B?SmV6MU5icUllTklIR3VQczNwWkg0UWRGbDRvZTdpWEE3MnNGa216LzNidW1E?= =?utf-8?B?a09lek43bXdsMFlYbWJ1RHNaVW1QWWlEWFZJcnBNUGVHUHg1SU9GYVFJNVgz?= =?utf-8?B?TmwxRFRBWHVMWktGS3VyTFh1U1hIa05FbGhvVGhIa3VPdWgyRVhoK3F4VmJT?= =?utf-8?B?cm51emtwcThrWmpsV2xpYzBpNGppajh5bVhPUkVTMlFYVVpFM212czlWbDFJ?= =?utf-8?B?cG81N0FhMWc0UzBJUnJ5L3pCZWI5cVNPd2t6MXhjOEpNY1RFcW1vT0FYSjVo?= =?utf-8?B?UFVkVG81VnFjd1Z0NTN0WkpxRUpYTVVGVmJmSHpaV3RTMUhEWnBSdmJHbDg4?= =?utf-8?B?ZEZBRHcyWS9pYWxNdjdEamZPa2ZETVd1Vm1kdzNlNFdhY2VHR3RQanRZbUpq?= =?utf-8?B?VzdBN0VwU3JEVENnNHl3VDFPL0YzVGlxQWtMaitBeElYNS9adGUzcFlxZWpy?= =?utf-8?B?VlhoVENyWHZvRElNM0ZMZDZONC8ySmdrNko2Qk1aMDFSeEtBdTFqOC9XUG1O?= =?utf-8?B?LzdYRTdwUWZ3YU8wZk1yMkx1U0wzd1IrMnpTN3Jva25PZ2RoVjU1NS94YVc2?= =?utf-8?B?elVscGNjVk5PNTJMYU5pSHpxb1JYcVlNbVc1bXFoekc1eFhSeTRWYWlqZnlk?= =?utf-8?B?cEhOSW9yU0tiV1VNVXVLQnhrNG5JSkRNbWlLb1NEdkdnaGwxMGh1VXdpS2lB?= =?utf-8?B?YWhNeXgyQnlmQ1JQYndEcHdnVlQ4VnErekhML0NPQlBwSVQyOGc1UDkxVHpa?= =?utf-8?B?cjl0RkZncGJqWWJCUFcxaHB3TkR5c3VJa0lwa1lwMWxQVFVsR1RJQUlnTklu?= =?utf-8?B?d0lCcG9UcTZWb1RTM3lKVzU4TmRTZEpCTXVPOTBZZDczMjJPRHJOODhxdmhu?= =?utf-8?Q?bGbbOxVMfQeO2GKKCL2i+eYcNx3u/cudkVXE/gY?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 91e45281-b783-42b9-1ae1-08d92ab19da0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2021 19:14:18.9728 (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: YA9G67T1bn25QNgjzOQ9+Df7is00Onnb6ahqg0jGv2W2uBAya2fQ9qVdcNFcXiGMMVOGFpmZGOFeggYX/y2Xzw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2126
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OuR-YjIAh19W-PJ4dr28PIlnaNA>
Subject: Re: [Idr] Rtgdir early review of draft-ietf-idr-bgpls-srv6-ext-07
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2021 19:14:29 -0000

Hi Adrian,

Thanks for your detailed review and apologies for the delay in responding.

We have published an update that addresses the comments as mentioned inline below. We can continue discussions for open items, if any.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-08

Please check inline for individual responses.

-----Original Message-----
From: Adrian Farrel via Datatracker <noreply@ietf.org> 
Sent: 30 May 2021 02:50
To: rtg-dir@ietf.org
Cc: draft-ietf-idr-bgpls-srv6-ext.all@ietf.org; idr@ietf.org
Subject: Rtgdir early review of draft-ietf-idr-bgpls-srv6-ext-07

Reviewer: Adrian Farrel
Review result: Has Issues

I have been selected to do a routing directorate "early" review of this draft. https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-srv6-ext

The routing directorate will, on request from the working group chair, perform an "early" review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft's lifetime as a working group document. In this case, it appears that the review request was triggered by the request to the AD for publication. The purpose of this early review is to ensure as wide of a review as possible.

For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-idr-bgpls-srv6-ext-07.txt
Reviewer: Adrian Farrel
Review Date: 29-May-2021
Intended Status: Standards Track

== Summary ==

Some minor issues and lot of nits.

== Comments ==

I am one of the Designated Experts for the BGP-LS registries and I had previously considered the draft when an Early Allocation request was made. That request was approved.

The document is clear enough and I believe I could implement it if I had to. The approach described in this document is consistent with the body of BGP-LS work, but I think it is important to note that the mechanism set out here differs slightly from the mechanism defined to do similar function with SR-MPLS. This distinction is clearly made in Appendix A. However, the WG chairs and AD will want to be sure that the WG recognise this difference and are OK with having two slightly different mechanisms running side by side.

There are some Minor Issues that I think should be addressed before IETF Last Call in case they create any points that community review might object to.

There are also quite a lot of nits in the document. I have tried to capture them below, but the large number means I may have missed some.  
I recommend fixing these before IETF Last Call so that other reviewers has a cleaner document to look at.

== Minor Issues ==

You will need to reduce the number of front-page authors to five or fewer, or you will need to provide the document shepherd with a credible reason to diverge from this rule.

---

Section 1

   On the similar lines,
   introducing the SRv6 related information in BGP-LS allows consumer
   applications that require topological visibility to also receive the
   SRv6 SIDs from nodes across a domain or even across Autonomous
   Systems (AS), as required.

I caution you to be *very* careful with the word "domain". The IESG has recently been concerned by the definition contained in 8402. In that document, the "SR domain" (also just "domain") is the collection of all interconnected SR-capable nodes. Here (and in other parts of the
document) I think you are using "domain" in a more restricted sense. I don't know how you fix that, but I believe you should do something.
Perhaps you can call out the terminology issues here by noting the 8402 definition and specifically defining what you mean by your local definition of "domain".
[KT] The "domain" is "IGP domain" in this context and this is fixed.

---

Section 2

   The SRv6 SIDs associated with the node are advertised using the BGP-
   LS SRv6 SID NLRI introduced in this document.  This enables the BGP-
   LS encoding to scale to cover a potentially large set of SRv6 SIDs
   instantiated on a node with the granularity of individual SIDs and
   without affecting the size and scalability of the BGP-LS updates.

The claims of scalability are not expanded here or anywhere else in the document. Scalability of BGP-LS is important, so I'd prefer some explanation. But if that isn't available, it might be better to leave out these mentions.
[KT] Advertisement of large number of SRv6 SIDs as part of the BGP-LS Link Attribute associated with the existing Node NLRI would make that BGP-LS update rather large. Using the new separate SRv6 SID NLRI alleviates the problem. This is the scalability consideration for the protocol encoding design. I am not sure what further details are required.

---

4.1, 4.2, and 7.2

You should consider asking IANA to create a registry for the flags fields. This would make it easier to keep track of future assignments.

You should also state clearly that the three flags fields are aligned so that an addition to one is always also made to the other (if this is the case).
[KT] The flags fields follow the IGP encodings but I agree that we do need to define the flags registry in IANA for the BGP-EPE use-case. Please see further below.

---

4.1 and 4.2

      Sub-TLVs : Used to advertise sub-TLVs that provide additional
      attributes for the specific SRv6 SID.

You need to say where these sub-TLVs are defined. If there are none defined yet, you should say so and explain why some might be defined in the future. 

You should also say where the sub-TLV type values are tracked.

Compare with 5.1
[KT] Added forward reference to sec 8 for both 4.1 and 4.2 that defines a sub-TLV.

---

5.1

You should say where the sub-TLVs are tracked, and you should consider a registry for the flags.
[KT] ack

---

7.1

   The SRv6 Endpoint Behavior TLV is a mandatory TLV that MUST be
   included in the BGP-LS Attribute associated with the BGP-LS SRv6 SID
   NLRI.  

What if it is missing?
[KT] The consumer of the BGP-LS information would not be able to use this information. The BGP-LS speakers themselves do not perform semantic validation for the TLVs per RFC7752 and this is clarified further in the draft-ietf-idr-rfc7752bis.

---

8.

   The total of the locator block, locator node, function and argument
   lengths MUST be less than or equal to 128.

What if they add up to more than 128?
[KT] Same as above.

---

Well done for including Appendix A. I assume that the WG discussed the relative merits of having a slightly different approach for SR-MPLS and SRv6, and contrasted that with the benefits of a consistent approach. I personally think that making a difference is unfortunate, but if the WG was happy with this decision then I guess it's OK.

Without launching into a sales pitch, it might be nice if Appendix A was to very briefly explain why the difference.
[KT] I believe the current text does already and not sure what more is required.

== Nits ==

You have:
- "SR for [the] MPLS data-plane" (Abstract)
- SR/MPLS (Section 4.1)
- "SR with [the] MPLS data-plane" (Section 7.2)
- "SR-MPLS" (Sections 10 and 11, Appendix A)

8402 has "SR-MPLS"
[KT] Ack - will use SR-MPLS.

---

Abstract

s/Segment Routing (SR) over IPv6 (SRv6)/Segment Routing over IPv6 (SRv6)/

s/by the various/by various/

OLD
   BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
   to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
   to the BGP-LS to advertise SRv6 Segments along with their behaviors
   and other attributes via BGP.
NEW
   This document defines extensions to BGP Link-state (BGP-LS) to
   advertise SRv6 segments along with their behaviors and other
   attributes via BGP.  The BGP-LS address-family solution for SRv6
   described in this document is similar to BGP-LS for SR for the MPLS
   data-plane defined in a separate document.
END
[KT] Ack to all

---

Section 1

s/A SRv6 Segment/An SRv6 segment/

OLD
   The IS-IS [I-D.ietf-lsr-isis-srv6-extensions] and OSPFv3
   [I-D.ietf-lsr-ospfv3-srv6-extensions] link-state routing protocols
   have been extended to advertise some of these SRv6 SIDs and
   SRv6-related information.
NEW
   The IS-IS and OSPFv3 link-state routing protocols have been extended
   to advertise some of these SRv6 SIDs and SRv6-related information
   [I-D.ietf-lsr-isis-srv6-extensions],
   [I-D.ietf-lsr-ospfv3-srv6-extensions].
END

s/Certain other/Other/

s/On the similar lines/On similar lines/

s/(e.g./(e.g.,/
[KT] ack to all

---

Section 2

   o  SRv6 SID of the IGP Adjacency SID or the BGP EPE Peer Adjacency
      SID [RFC8402] is advertised via SRv6 End.X SID TLV introduced in
      this document (Section 4.1)

   o  SRv6 SID of the IGP Adjacency SID to a non-Designated Router (DR)
      or non-Designated Intermediate-System (DIS) [RFC8402] is
      advertised via SRv6 LAN End.X SID TLV introduced in this document
      (Section 4.2)

1. s/SRv6 SID/The SRv6 SID/ twice
[KT] Ack

2. It is confusing that the first bullet talks about advertising the
   IGP Adjacency with no qualification, but the second bullet talks
   about the IGP Adjacnecy to a non-DR or non-DIS. That appears to make
   the first bullet a superset of the second bullet. Sections 4.1 and
   4.2 make this a lot clearer: perhaps you could bring some of that 
   clarity to these bullets.
[KT] This is just the intro and there is a pointer to the sections where things are described in further details.

---

Section 2

   o  SRv6 Locator is advertised via SRv6 Locator TLV introduced in this
      document (Section 5.1)

s/SRv6/The SRv6/
s/SRv6/the SRv6/
[KT] Ack

---

2.

   The SRv6 SIDs associated with the node are advertised using the BGP-
   LS SRv6 SID NLRI introduced in this document.

Please include a forward pointer to Section 6.
[KT] ack

---

2.

   o  The endpoint behavior of the SRv6 SID is advertised via SRv6
      Endpoint Behavior TLV (Section 7.1)

s/via SRv6/via the SRv6/
[KT] ack

---

2.

   o  The BGP EPE Peer Node and Peer Set context for a Peer Node and
      Peer Set SID [RFC8402] respectively is advertised via SRv6 BGP EPE
      Peer Node SID TLV (Section 7.2)

s/via SRv6/via the SRv6/

The text is hard to read. Maybe...

   o  The BGP EPE Peer Node context for a Peer Node, and the Peer Set 
      context for a Peer Set SID [RFC8402] are advertised via the SRv6 
      BGP EPE Peer Node SID TLV (Section 7.2).
[KT] Ack

---

2.

s/(e.g./(e.g.,/
[KT] ack

---

2.

   When the BGP-LS router is advertising topology information that it
   sources from the underlying link-state routing protocol (as described
   in [RFC7752]), then it maps the corresponding SRv6 information from
   the SRv6 extensions for IS-IS [I-D.ietf-lsr-isis-srv6-extensions] and
   OSPFv3 [I-D.ietf-lsr-ospfv3-srv6-extensions] protocols to their BGP-
   LS TLVs/sub-TLVs for all SRv6 capable nodes in that routing protocol
   domain.  When the BGP-LS router is advertising topology information
   from the BGP routing protocol (e.g. for EPE as described in
   [I-D.ietf-idr-bgpls-segment-routing-epe]), then it advertises the
   SRv6 information from the local node alone.

I'd suggest moving this paragraph to be the second in the section as it explains what is going on.
[KT] ack

---

3.1 and 

   This TLV maps to
   the SRv6 Capabilities sub-TLV and the SRv6 Capabilities TLV of the
   IS-IS and OSPFv3 protocol SRv6 extensions respectively.
   :
   :
   o  Flags: 2 octet field.  The following flags are defined:

     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | |O|       Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 2: SRv6 Capability TLV Flags Format

      *  O-flag: If set, then router is capable of supporting SRH O-bit
         Flags, as specified in [I-D.ietf-6man-spring-srv6-oam].

      *  The rest of the bits are reserved for future use and MUST be
         set to 0 and ignored on receipt.

Would be good to include references for the two capabilities TLVs.
[KT] Ack - added references.

It would also help to not include the bit definitions here. I think I am correct that if a new bit is defined for inclusion in the ISIS SRv6 Capabilities sub-TLV flags field, you expect to pick it up here automatically.
[KT] Ack - removed those bit definitions.

It looks like the mapping is in the wrong direction. I.e., this TLV maps from, not to, the IGP TLVs.
[KT] Ack

I think you would say... 

   This TLV maps from
   the SRv6 Capabilities sub-TLV of the IS-IS SRv6 extensions [ref] and
   the SRv6 Capabilities TLV of the OSPFv3 SRv6 extensions [ref].
   :
   :
   o  Flags: 2 octet field.  The contents of this field are copied from
      the IS-IS or OSPF SRv6 Capabilities TLVs and have the same
      meaning.


For what it's worth, it's a pitty that there is no registry for tracking the flags, but that's a problem with draft-ietf-lsr-isis-srv6-extensions
and not with this document.
[KT] The latest version of the ISIS SRv6 spec does introduce the registry for the flags and the equivalent OSPFv3 will be also updated on similar lines.

---

4.1

s/End.X with USP and/End.X with USP, and/   (twice)
s/This TLV is also used by BGP/This TLV is also used by BGP-LS/
[KT] ack

---

4.1 Figures 3 and 5

Convetion is that if you show all of the bytes, you close the start and end of the lines with a vertical pipe "|". Or you can leave out bytes and close the line ends with a tilda "~" or double slash "//" (see Figure 9).
[KT] Ack

---

4.1, 4.2, 5.1, and 6.1

Can you say what the Length field is. "The length of the value part of the TLV in bytes including any sub-TLVs that may be present." ??
[KT] This is base BGP-LS encoding. I don't think we need to repeat it for each TLV that is defined.

---

4.1, 4.2, 5.1, and 7.1

      Algorithm: 1 octet field.  Algorithm associated with the SID.
      Algorithm values are defined in the IANA IGP Algorithm Type
      registry.

It would be good to add a reference to RFC 8665  or to https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml.
[KT] Ack

---

4.2

s/normally an IGP node only/an IGP node normally only/ s/to announce SRv6 SID/to announce the SRv6 SID/ s/(i.e./(i.e.,/
s/End.X with USP and/End.X with USP, and/   (twice)
[KT] Ack

---

4.2

   The IS-IS and OSPFv3 SRv6 LAN End.X SID TLVs have the following
   format:

Do you mean the BGP-LS TLVs?
[KT] Yes - fixed.

---

5.1

OLD
   As specified in [RFC8986], an SRv6 SID comprises of Locator, Function
   and Argument parts.
NEW
   As specified in [RFC8986], an SRv6 SID comprises Locator, Function,
   and Argument parts.
END
[KT] Ack

---

6. Figure 9

There is a broken format line in the middle of the figure.
[KT] Fixed

---

6.

The figure has
    |                        Identifier                             |
    |                        (64 bits)                              |
and the text has
   o  Identifier: 8 octet value as defined in [RFC7752].

Be consistent?
[KT] Not sure that I follow - 8 octets = 64 bits. We've tried to keep the figure aligned with RFC7752. While this document describes fields in terms of octets - so it is consistent.

---

6.

   o  Protocol-ID: 1 octet field that specifies the protocol component
      through which BGP-LS learns the SRv6 SIDs of the node.  The
      Protocol-ID registry was created by [RFC7752] and then extended by
      other BGP-LS extensions.

- s/Protocol-ID registry/BGP-LS Protocol-ID registry/
- Probably, "...and then additional assignments were made for other
  BGP-LS extensions."
[KT] Ack

---

7.1

s/are bound with a SID/are bound to a SID,/
[KT] Ack

---

7.2

s/The similar/Similar/
[KT] Ack

---

7.2
   is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID Is that "OPIONAL"?

But then...
   This TLV MUST be
   included along with SRv6 SIDs that are associated with the BGP Peer
   Node or Peer Set functionality.
... is confusing.

I suspect that the second sentence should be...
   If this TLV is present, it MUST be accompanied by the SRv6 SIDs that
   are associated with the BGP Peer Node or Peer Set functionality.
[KT] This TLV is actually mandatory (as indicated by the MUST in the next sentence) for SRv6 SIDs related to BGP EPE functionality. Fixed in the text.

---

7.2

s/For a SRv6/For an SRv6/
[KT] ack

---

8.

s/SRv6 SID Structure TLV is used/The SRv6 SID Structure TLV is used/
[KT] Ack

---

8.

   optional TLV

Is that "OPTIONAL"?
[KT] I haven’t seen OPTIONAL used for such TLVs in RFC7752. It is always been "optional". I believe the lower-case use is correct in this context as well.

---

9.

OLD
   This document requests assigning code-points from the IANA "Border
   Gateway Protocol - Link State (BGP-LS) Parameters" registry as
   described in the sub-sections below.
NEW
   IANA has made early allocations of code points from the "Border
   Gateway Protocol - Link State (BGP-LS) Parameters" registry as
   described in the sub-sections below.  IANA is requested to updated
   the references to indicate this document when it is published as an
   RFC.
END
[KT] There is some change here due to the new registry sub-section.

---

9.2

It would make sense to list the codepoints in numeric order. I.e., lift
518 to the top.
[KT] Ack

---

10.

s/(e.g./(e.g.,/
[KT] Ack

---

11.

s/(e.g./(e.g.,/
[KT] Ack

---

Appendix A

s/session(s)/session/
s/advertised as attribute/advertised as attributes/
[KT] Ack