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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Tue, 01 June 2021 14:42 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 3B7A63A1A84; Tue, 1 Jun 2021 07:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.896
X-Spam-Level:
X-Spam-Status: No, score=-11.896 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_MED=-2.3, 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=Clnts4vo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tlAJApOe
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 KfkqAwDShqQp; Tue, 1 Jun 2021 07:42:19 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BB13A1A83; Tue, 1 Jun 2021 07:42:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21134; q=dns/txt; s=iport; t=1622558539; x=1623768139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dkAbY12x+CW883DJrWVOcDGDnTUL8dyKzykbc3t3wS8=; b=Clnts4voVpFNrT72cswHvXfCnk1B3J4wlMqj5hETS6ddTcr9Iiw3hON8 56A5y6rVdEopeDxJj65AM0ODh5vW9jCHs93RUr2xCTbhRDHONUfDURAfW XxtZylyTD0V5wLHusIqPE+bcMWzm6Wm6A85dq5tGNw/A1uT+ZqUlp0mZt s=;
X-IPAS-Result: =?us-ascii?q?A0AZAADDRrZgl4cNJK1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UMHAQELAYFSIwYoflo3MQuEPYNIA4RZYIhuA49Pij2BLoElA1QLAQEBDQEBN?= =?us-ascii?q?QoCBAEBhFACF4FnAiU0CQ4CBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBA?= =?us-ascii?q?QEBAQFohTsBBQEmDYZEAQEBBBIREQwBASkOAQsEAgEIEQMBAQEDAiYCAgIwF?= =?us-ascii?q?QgIAgQBDQUIDAcHgk8BglUDLwEOnEIBgToCih96gTKBAYIHAQEGBASBSEGDI?= =?us-ascii?q?BiCMQmBECoBgnqEDoZhJxyBSUSBFAFDgl8+glcLAgIBgV8VD4JxNoIugVgBP?= =?us-ascii?q?hQZagQNNg8BIi4jDAYTLBUOAg4LAQkGDAMPCTuUPIwlmnoKgxmKDoZWVoZfh?= =?us-ascii?q?WkRg16BQolZhiiQN5VHjBWTDwoECw0BhFcCBAIEBQIOAQEGgVQ5gVtwFTuCa?= =?us-ascii?q?QlHFwIOiVUBhEkJAw0JgQIBCIJDhRSFSnMCNgIGCgEBAwl8iU0BgRABAQ?=
IronPort-PHdr: A9a23:YLhwqRG3P/y4qOyQ1BlaWp1GfsIY04WdBeZdwp0jh75JfeKo+NL/P x+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANMn1NicgfkwE6RsLQD0r9Ia3tayA2G 8sEX1gj4nLoeURQEdz1MlvVpHD65DUOGxL5YAxyIOm9GoPbg8mtke6o/JiGaARTjz37arR3f 32L
IronPort-HdrOrdr: A9a23:NZoYJqOs1ZVgr8BcTxT155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHPlOkMgs1NaZLUfbUQ6TTL2KgrGSuAEIdxeOk9K1kJ 0QD5SWa+eATWSS7/yKmjVQeuxIqLLsnczY5pa9854ud3AWV0gK1XYeNu/vKDwPeOAwP+tBKH Pz3LsimxOQPVAsKuirDHgMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlul9yZbdwkK7aYp8G DDnQC8zL6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4oow3TX+0OVjbZaKvq/VQMO0aeSAZER4Y DxSiIbToBOArXqDzmISFXWqlLdOX0Vmg7fIBej8AveSIrCNWgH4w4rv/METvMfgHBQ4e2UmZ g7rF6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOLFuJYO5gLZvt3+9Kq1wVh4SKbpXZt WGB/usqMq+sWnqJ0wxm1Mfj+BEck5Daituc3Jy8/B9iQIm6UyR53Fos/D3sE1whq4Adw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.83,240,1616457600"; d="scan'208";a="702743746"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jun 2021 14:42:17 +0000
Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 151EgHKY000816 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Jun 2021 14:42:17 GMT
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 1 Jun 2021 09:42:17 -0500
Received: from xfe-rcd-001.cisco.com (173.37.227.249) 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.792.15; Tue, 1 Jun 2021 09:42:16 -0500
Received: from NAM10-DM6-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.15 via Frontend Transport; Tue, 1 Jun 2021 09:42:16 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dklZQ9jJ/CMY1nmNUL9TjNoOq6OmXIX9lKYTmWRvPMeB2GKrZSUtWoA85YVUoxEDS3pJsDviPLsnMFwtAG74Csy4+hcOQHwxhVzYiWxXcybmR8gI1/7n0kGEOHvhF/uEL31mW0EFOHWfiiXdYLtSh55UMj2N+wAFFuzUkashonX0l88thAf0j6Pcfr5osWR/T9mf8/hBhOmOG5GEW/tnERD+O9WGAIcgU6jEs8xmhw9GmcYW6OZCepVuEvcpzU9BGie4cghp/e88Qy7hqYktFzf+nctbYdHvYdaMehaewemDg2Q4D9+HB3i+zliOU+Amrpow7no35Nn1nFC91Jvz7g==
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=dkAbY12x+CW883DJrWVOcDGDnTUL8dyKzykbc3t3wS8=; b=P5tVsPL1XrWDqC2+Jf937/Jdr4f3WRT5nV7LwdG8CSqmB3TzsE03NfkaLgF3VXkU0b7FPnVfsL959o/CUSCAb0qTIKnqdrZp0F2KyYFM8MWmv8wN1fJ2SYx2mGin8avXCP8KmqxEXDmPvtZVUUD380XK6CUzCBc0Vweag9IctkFVSmkjc1kZfqch4KMNihyuv4sWXGdDNNkG3fLB49xq+PieZ7sEmT/yk0KU2yOy52neyKVMt+8JvfiQHUpGh5OXrTYlDxi5MQFEo7D1JgjREUYe6zzkbRFNlKGgmyl4R2iArALo6XDBy6JCIjd4QQ9LHUDowKK12r3vd+vIKz7mOw==
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=dkAbY12x+CW883DJrWVOcDGDnTUL8dyKzykbc3t3wS8=; b=tlAJApOegSH6avJyhr08HizeZaKC/+j8FweQTOjDixXssansxbrhdVL403GOz+SKyrUV2njtO6c5enNanpT6m6Hfht1UdqcbaFer1EMhU31m9J3s3lB0Y/lko5qAtLZgll+gyGj/aYpTR95epGIoKj1CkDm7K3DoIzovQr+m9SQ=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2128.namprd11.prod.outlook.com (2603:10b6:301:55::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.27; Tue, 1 Jun 2021 14:42:15 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::ec42:2e34:fc81:d45f]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::ec42:2e34:fc81:d45f%5]) with mapi id 15.20.4173.030; Tue, 1 Jun 2021 14:42:15 +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: AQHXVNBrwCpZivHRgUqYKOXpCmUudqr/PsZw
Date: Tue, 1 Jun 2021 14:42:15 +0000
Message-ID: <MW3PR11MB4570C4B8C4578A38E8BB4C76C13E9@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.13]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f839033f-ca6a-4a66-65fe-08d9250b730b
x-ms-traffictypediagnostic: MWHPR1101MB2128:
x-microsoft-antispam-prvs: <MWHPR1101MB212892F812B9A83DADAC153FC13E9@MWHPR1101MB2128.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: TdC4BPyooEckNv7y6b0Nq4+WSmOm173nBlwbeZIm4fYJvIzBQ/cx04z3+YgjLFfN53xAuYkYwvmuyO0jWoliTJNa6mKUGfklhNfjknwXs/mDjbNDd/Uo0YunQoqWtCjJQ24L0IK6deExe/oQ6W7CsIoFdYkFDzNMw/tvOq8e/E7BNFhpTFStwvhxkYndDTyVXGYG+1zPJwtpAgocmVam5BtxaxTubMSfZwMVtQ4PIzxmI1WxUvrBRXDnvL489wvLSASOlkaYZ7f3Xh1PMnBseFkORzexure+zscMrv60LfaxmVl4oP5A/PcbOuZZ8Cq7cieZpRyxpkdhdgwb+nkQ+hR7GsQj1yY+Yj1zph4wSdYJTNZssrSclDPHIAutzr+9uSh4YdMrAjYZSoGKLActZ9r1c2HLX79h7OQhR96BDB8/XwgxituD0gE1oxU43zVN2kgdgjdvlWA/2N4u/9oHiINsfitkxi5Hq8lzT4pPUDfBxl5SdwY0CdtD1jxQ2KPmffpAcQKle+PiIB0x7z6S5CYUfJFBJUmf1XtgwLiSg4Jp71kl0G+AEk0OdgZy9EhaXFO+6z7qRM51nsWFDMhvyap6/L3NfxDyVy0WVaKhsBL2TUts1twe60QKM7H565PqW8gCwPSm5HnurkoRsmmgMni21MUy2WEnMH9AU6tAT5feazMJlOvoqXKOiVy2gWG41Iqrvbp4/MVDh0xSkFKqkRBBbH423jhDzXeszHSyZ2mZhO78QxQibyZ167KrAkt2
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:(366004)(39850400004)(376002)(346002)(396003)(136003)(110136005)(186003)(316002)(66476007)(66574015)(76116006)(5660300002)(54906003)(26005)(66946007)(66556008)(64756008)(33656002)(7696005)(478600001)(30864003)(53546011)(6506007)(9686003)(83380400001)(86362001)(2906002)(4326008)(55016002)(71200400001)(52536014)(8676002)(8936002)(966005)(66446008)(38100700002)(122000001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?SlIrQUhHQ201aXJFTFZEcmhKdmlROTJwSWNScFlJV2JnNjRYZ2E4SGNrZzJy?= =?utf-8?B?UVMrK0VPbVRJVHU0OFRVU2FqMGFHTW93SXBqNnNSYkF6ZHBQTWM5Z3pzSm5n?= =?utf-8?B?VTE2cjJ1Nmdvald2UWpqWHhSMFU1YSthazEzUlZqUFRremhsNTVVbTFyUG1B?= =?utf-8?B?dFBRU3BBUVg2a3hzUS9iY0xaYUwyM1ltZ2NaN1ErNlB2NitILzNndCs5eDNP?= =?utf-8?B?MGxwTWFTdENyYjlxY1VuU0I2WWdYZ0JnM0lZcXk5azBNRWdQZEE2YlkrQlVB?= =?utf-8?B?dGN6S2NiUkovbHlGcUFpQ1U2cExCV1pJYlUxRkxMQy83NlkrSVV6T0NkMzly?= =?utf-8?B?dExXY3NQajAwdFd1bEtESUZMZ3R3VmJqRGNYVHdFR3lhS1dOYWVVOGJFY3ZW?= =?utf-8?B?MkMvNi9hRitvaGFPb1dFZHJNZDUzM1lIUG5aMUtyWkJiSWg4eUxydDFjSno3?= =?utf-8?B?UTdUejFTVzhxd1E4VjJMZ3kzS0lYeGtLeTg4aVlDaFpVTVc5K2ZHdVZTUjU3?= =?utf-8?B?UFRjbVpFR2p5dW9UU2ZrdTV6UXQ2aVlmYzU5S3lDSnVEem81K2I3STNsenI3?= =?utf-8?B?ZWdoUDFYbGlVYmRzelQwbkZYSjhqWldoK2dqR1pVSVd3bXduaExDMlZwemhm?= =?utf-8?B?VEdDOWk0ZGYvUCtVbGl1OS83Q3crS3dwbUhFQ1RpK0FsL2xabWx1UHdSV0lR?= =?utf-8?B?Y2U2K1NNbWhhcTZpd3E5ZGorUm4zN0JNWmVVVGNQRnhWcnNvaHdOYjVxdWxX?= =?utf-8?B?dXZTbDc1c0g1eFBzbTdNQThhM1FMU3d3Rk1nWnVmcnVNN3F6azcxc2QzZ1p0?= =?utf-8?B?MXArN1VPZEdVczZBWExyeWYzNDZsSVMwOUFEbHBqOER5MStTQ3hQVHdCMTlD?= =?utf-8?B?bDlrMXlXbWQrSFFnZFduNDJNSTF0SlpPQ0RscjF0VGNSUWFsQk04SWRhd0RZ?= =?utf-8?B?N1BHeUJxNDNYUEtrTDh6RVlpK0ppSms0SGdkZCtqWFVzdjJWQ0xNRlNpMGJN?= =?utf-8?B?TTRTMHVaNjRCbWl4aktQMTRpRTE4cWg3OERPT2ZKV3ZZckhzRWFVenUvU2px?= =?utf-8?B?Nyt1TnVxNFdCM09NdFcxZnBmbThuZk02VW5SelZ4T2tFbE1LYVNmcDhoUzha?= =?utf-8?B?K0U4azZzUHN0TjNVWlZ4NGh2a040cmIwQTZLc21kbVFuTTdmajJUN2czZVBB?= =?utf-8?B?Z2ZyTGIwckZBS1NiR2VoaFpmQ0phblJQUWx6cHZOV1J0TG91NldxNENKSnZl?= =?utf-8?B?ZUpnMFdFSU8vL011bUtNZ0kzdnV3K2ZWckZWemNXUGU4cG5QUDE5ZmFFMTgw?= =?utf-8?B?N0tzOVNseVArSTZhL0JZZlBxQmwySWZXWmtMVVRLUC8wb1ZNaVppYkRHR0xY?= =?utf-8?B?NWVSKzhUQkJ5cm1tdkxLYmlkVnQ1RmlZUkJUUS9aQ1FiNGd0ZThLby8xc00w?= =?utf-8?B?NXcxbFZia2VOSUNlZUVCV3Y1V1htamwyTDlXR1VmdW0zRVRsc1BTKzMvM2hm?= =?utf-8?B?SVlsTm9sUk80UFhmUWs0ZmY0UVRqb1k3cnRUbWI2SHZydkRPc20zRURKS2Vs?= =?utf-8?B?dkVSM1RIdExrTnlkOExydFM0bjBhZGdkV3JNOUFEbUFVaFc5VlpYdXA2c29U?= =?utf-8?B?TzFMZG1GQkEyeldzZkRSQTd4R21nR0FrdnFOYUxLeGdCVWQ5SGtXYVRoaUJO?= =?utf-8?B?T0o4aVMvalJ4SkhOek9rQXFxWmpzM2JKOGNrR2RZeG1WZnp4UUNTQnhMRWVx?= =?utf-8?Q?bHvdeuOtWh1buljR7/6kxuPyU5+hPWzdU9Oys2V?=
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: f839033f-ca6a-4a66-65fe-08d9250b730b
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2021 14:42:15.2619 (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: mRLjwyr9JzN337iHvMK1CbX1ALuF5f3F0nh3wN9yHP2VPR9ScF/eELvADm9qhci5tgKu8RYYzeFvJjxmFlabKg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2128
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/e_cE9KtvXPX6cr4n4dlQoOeo0Ik>
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, 01 Jun 2021 14:42:24 -0000

Hi Adrian,

Thanks for your detailed review and comments. This is a quick note to let you know that we are working on addressing your comments.

Thanks,
Ketan

-----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".

---

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.

---

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).

---

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

---

5.1

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

---

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?

---

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?

---

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.

== 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"

---

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

---

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.,/

---

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
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.

---

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/

---

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.

---

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/

---

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).

---

2.

s/(e.g./(e.g.,/

---

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.

---

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.

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.

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

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.

---

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/

---

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).

---

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." ??

---

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.

---

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)

---

4.2

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

Do you mean the BGP-LS TLVs?

---

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

---

6. Figure 9

There is a broken format line in the middle of the figure.

---

6.

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

Be 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."

---

7.1

s/are bound with a SID/are bound to a SID,/

---

7.2

s/The similar/Similar/

---

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.

---

7.2

s/For a SRv6/For an SRv6/

---

8.

s/SRv6 SID Structure TLV is used/The SRv6 SID Structure TLV is used/

---

8.

   optional TLV

Is that "OPTIONAL"?

---

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

---

9.2

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

---

10.

s/(e.g./(e.g.,/

---

11.

s/(e.g./(e.g.,/

---

Appendix A

s/session(s)/session/
s/advertised as attribute/advertised as attributes/