Re: [Idr] Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 12 March 2021 17:40 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 5006B3A1847; Fri, 12 Mar 2021 09:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=A/hjazkA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ma8Fhxc4
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 mGlQwb7SRVWY; Fri, 12 Mar 2021 09:40:30 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8EA3A1844; Fri, 12 Mar 2021 09:40:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69236; q=dns/txt; s=iport; t=1615570830; x=1616780430; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AC3lhGUliOTwNBDgf4SAR9LCgrN4PukIuhip/x+Di7o=; b=A/hjazkAGt3AcNE9vCKuQvDmKgXhNlRUnBh8AfjPpgKobXsMx23byMnE Z7GhBQvHU+K0/nKzFEjQC+ppt4V3fA9jrCUbB0GIFz3dp+eLUKUSUqpgv lyJ8Ypk9o2ZSoRpusltxSLBKqaU/P8GP8aWfNbfKobpCEJdWMNmFfLflm Y=;
X-IPAS-Result: =?us-ascii?q?A0BYAACspktgkIcNJK1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFPgSMwIy59WjYxiAkDhTmIQAOBB5gkgUKBEQNUCwEBAQ0BA?= =?us-ascii?q?SoIAgQBAYE3gxYCgXQCJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBh?= =?us-ascii?q?jgNhkQBAQEBAxoTEwEBKQkFAQ8CAQgOAwQBASEBBgcyFAkIAQEEAQ0FCBECg?= =?us-ascii?q?lUBgX5XAy8BDqFgAooedIE0gwQBAQaBR0GDGRiCEwMGgTmCdoQHhB+CJyYcg?= =?us-ascii?q?UpCgRABAUKBWkk1PmmBdwEBAgGBJwERAgEiJAcJgxSCK4FYARABFAhEAQENA?= =?us-ascii?q?S4bCwQiKQYCIAIuCAIhChMsCA0EAQwBERYfBZBrDoRahigwjDSQRoELCoMBh?= =?us-ascii?q?DGFGIcMjASDPYpbhgKNJYJRlHKCDYlCkkKEPQICAgIEBQIOAQEGgWshaXBwF?= =?us-ascii?q?TuCaVAXAg2OHwwNCRSDOYUUhUVzAgE1AgYKAQEDCXyQP4FHfgEB?=
IronPort-PHdr: A9a23:GC8uOBY/fWAKiqKLt4uMR0D/LTDfhN3EVjU944c7i79IbqWo9ojjO 0qa//h2kVvVRu3z7f5Wi6zdtKWzEWAD4JPUtncEfdQMUhIekswZkkQmB9LNEkz0KvPmLklYV MRPXVNo5Te3ZE5SHsutYVHAoju56jtBUhn6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oa husqgCEvcgNiowkIaE0mXP0
IronPort-HdrOrdr: A9a23:x/luvq+DqL6XnFbh0eVuk+GKcb1zdoIgy1knxilNYDRvWIixi9 2ukPMH1RX9lTYWXzUalcqdPbSbKEm8ybdc2qNUGbu5RgHptC+TLI9k5Zb/2DGIIUPD38Zn/+ Nbf6B6YeeeMXFTh8z3+RT9Nt4mzsWO/qzAv5ag815GZ2hRGsZdxi1+DRuWFVAzYQFAC4YwGp b03Ls4mxOLf3MLYsOnQkQURuSrnayEqLvKQz4jQyQm5g6HkC+y5NfBcySw8x8CX1p0sMwf2E fflQiR3NTHj9iazVvm23bX/9BqnrLau6d+LeitruRQFTn2kAavY+1aKvy/lRQ4uvum5lpvsP SkmWZbA+1J53ncfn64rHLWsmGKultDmhySq2Owunftrdf0Qzg3EaN69P9kWyHE4EkttswU6t Ms40ultoFaBR6FvCPx68mgbWATqmOIoGEvmeNWsnpHUYF2Us4pkaUj+ipuYfM9NRO/zLpiPP hlDcna6voTW0iddWrlsm5mx8HpdmgvHz+dK3Jy+vC94nxzpjRU3kEYzMsQkjMr75QmUaRJ4O zCL+BBiKxOdMkLdqhwbd1xAvefOyjoe1bhIWiSKVPoGOUsIHTWsaP6570z+aWMdIEXyoAx3L DMSklRu2J3W0+GM7zN4LR7tjT2BEmtVzXkzc9To7JjvKfnebbtOSqfDF80lc+tpOgeH93bV/ 6/NIk+OY6mEULeXaJymyHuUZhbLncTFOcPvMwgZl6IqsXXbo3m39arN8r7Ff7IK3IJS2n/Cn wMUHzYP8Nb9H2mXXf+nVzUU3PpcUrv4IJoHMHhjq4u4blIErcJnhkeiFy/6M3OAyZFqLYKcE x3J66ilLi6q2mw9WPB9H5oJRJZE0ZQ7NzbIjZ3jD5PF3mxXacIut2Zd2wX9mCAPAVDQ8TfFx Mau0564rutL5ubxTkrDtWuNm7ytQpLmFu6C7Mn3oGT78bsfZ01Sqs8UKtqDAPRClheggBxsl pObwcCW27SHj7jkr+ekZQRHe3THuMM2DuDEIpxkzb/vV/ZjdwzTnEbNgTeIPK/sEILfX5ooX Fft4UYm6GNnD6zL3BXupVJDHR8LEKNALxHCwyZYp5zgb6DQnAqcU66wRqHlho0Zm3ms2IVi2 CJF1zIRdj7RnxAp3tfzqHmtGlRS1zYVUdxZndm2LcNT1jusmpv0OONe6q423aQbFxH2e0GLD TZe1IpU3BT7sHy2xiPlDmYE3I6gp0oI+zGFbwmN6rew3W3NeSz5Ow7Nu4R+JZuL9b1tOAXFe qZZg+ONTv9YtlZkDC9tzIgOCNurmMjnu6t0Br57HKg1Hp6BfbJOlxpS/UaJN6bhlKUDcqgwd F8jdgvu/G3PXi0YtmaybvPZzoGMwjNuweNPpcVgIERubh3uKp4HpHdXzeN3HZb3A8mJMOxkE 8FWqx07L3IJ4cHRb1fRwtJul4y0NifJkoitQL7RvUzelwglHfXNdKE6bigk8tmPmSR4A/rfV WP+SxU+PnIGzaZ3bkBEqQqPCBYblM/5HkKxpLMS6TATAGxM+dN81qxPiXjLPtTSK2ZFa4RqR g/6deShOOTfzf53geVvTYTGNM7z0+3BcepRASLEqpU9tb/P1KGiK6j+tSygzf6UiHTUTVQua RVMUgLKt1egTwjhpAt2ie8Sqbrslso+mEulA1PhxrowMy6+2/VEkFNLB3BjphXVTdVNGKUjc 6ty5nu6F3tpD5f2ZfCE09MftZBX9gIJ7KHXRtTFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,244,1610409600"; d="scan'208,217";a="653196106"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2021 17:40:21 +0000
Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 12CHeJMv005548 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 12 Mar 2021 17:40:21 GMT
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 12 Mar 2021 11:40:18 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 12 Mar 2021 11:40:16 -0600
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 12 Mar 2021 12:40:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S/ZIok5RQTECoaS9PzqrU6B7fGn/ebuwZAAIyvKe0qqjk4agd8bGiD8QcObqenBE+JUkLsXi36vm5u19KhBSRcphd7JPu1yasWHWZv/t6xYQ1WagFxOD8In1ODVJCB07K2+MhTV8I2cCHldm9Ad19kfFseD3oDSR2Zh4ugvuBQb1pQh7tJ9atgUCCfFlsSy2QxbYTQuOmvZKhFSTgFILGozCsk41DgO2hCJMF1ZtIXN1ikg2LBFrgVqVHdfss0qNcKpzlGY90xtkXWw8ODrtcNxuVHKIUhZIUSdVFUNnmwFDCdYQjh6fg/IemnvLSSWRvXJ58mbfcngBcEymLUuLBA==
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=aKexAl9l80m4XYPS4YsIj2hYLGsqoyAxqGz3W0u/HnU=; b=I4eeOf+FO/NMpg4Pd0A/7ReDXwtOhqhIZd8x2JGwO1IPooRh+onJVMuimHFkcB8o0HdPOZD2m7bVYhOI3fHrqhi9BiaRHxze9s2x2IYZkwRBn0eXzUhiy5vUPMWESwAebp0TIEW/MaKH5ihCY+qAX7mOtQR5MqwxKqvSi8zSjrfz4sagc2DgTbay7PJnPbX/75V5nzx8ibaE+jGmD7nXEhvDyjSTkfGrDddCYuOlk/3agPe6RE+bpz9rpRjrwpbcmp2urc0GL2tx1fclLhYLl6nhMzdttQQt3SMoZG9ctq8LwW5wpMo9y7pHJ8JsPGNW5u0SCLPyFP9uacEaydfBRA==
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=aKexAl9l80m4XYPS4YsIj2hYLGsqoyAxqGz3W0u/HnU=; b=ma8Fhxc4dYdmjtmX7LhF/wu8gTOK3lChDmsWy5kZzyb/cePkIbuXXCpojB+ny6IU7F1hbzDqYN4mvkKyIlAzbqsV4SulW8JXGl90N2jyTzqgqrQLuu19A0xtpTkLF0rH0ZOBjeSMFo7swyRIhaKNrRK+3BsCjYB9mm1x92LLEuY=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4761.namprd11.prod.outlook.com (2603:10b6:303:53::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Fri, 12 Mar 2021 17:40:14 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::912e:ea1d:5ec:ea30]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::912e:ea1d:5ec:ea30%3]) with mapi id 15.20.3933.031; Fri, 12 Mar 2021 17:40:14 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
CC: "draft-ietf-idr-bgpls-srv6-ext@ietf.org" <draft-ietf-idr-bgpls-srv6-ext@ietf.org>
Thread-Topic: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt
Thread-Index: AdcXPomj2jR5ZYBsTMC9P+mHDUVU7gAD+dEgAAPLQgAAAEGs8AABgT0AAABPjBA=
Date: Fri, 12 Mar 2021 17:40:14 +0000
Message-ID: <MW3PR11MB45702B002BCB9BD49740DE78C16F9@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <00b901d7173e$bb21ba80$31652f80$@ndzh.com> <MW3PR11MB45702E32F8A2F644261F659DC16F9@MW3PR11MB4570.namprd11.prod.outlook.com> <004b01d7175d$9ec09ea0$dc41dbe0$@ndzh.com> <MW3PR11MB4570222471A41E20B97B2C2DC16F9@MW3PR11MB4570.namprd11.prod.outlook.com> <007401d71764$b0ccf6f0$1266e4d0$@ndzh.com>
In-Reply-To: <007401d71764$b0ccf6f0$1266e4d0$@ndzh.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2405:201:1006:a1ca:745f:b7f7:d7f:9bfc]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3850806f-1197-456d-9d62-08d8e57de4be
x-ms-traffictypediagnostic: MW3PR11MB4761:
x-microsoft-antispam-prvs: <MW3PR11MB47618E422D13FECBFFE1F91CC16F9@MW3PR11MB4761.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: mPUkOVIe/TwEHFKVW0Y6DXP/Es+R7zin46Ez2lCyKoAUBy6CQtWxFJcXpBaXEL5i4W6EpkV+/ClUyLbhWjNXbXt7KkrTYBrHzOLpPLaUhNAP4KWIM+TegnxbsWduRK90keF07kgXwVLohdGJkX+3THt4fAFMP0aNy2ckjyFGwBvrPZVKlN2t4YciPrDdQ6LUKBboO1s6URX5MqEHEa8juQccL/vLjyN5sdc0wh9ygd33nKuu49vCLsxNRAzhefAd/kzyGgNaF6/8vjqbVdXkyNtQKj9bBMlFjUpNpc9+Eh0fslIygWCIvkeSOCOpTp/lGSDWHiOIRi6RcFEn2Md7iMhWaiPhirFN7GO6nFMtN37cCPle4F3KdgrJMYb87vBm1MeE7zHKC7GzoDh31xL1vtGnMT2Hq+5d9DQfxQbfHU5sgJPPS9QY8DTtSsgEft9l9agv87vhbEBYHHShdutp0tj5RpF0GDI7EWnR4Kro4YDArKd2JbjBrGn2dWVMKG/OcN1r1/AvkdL5EcsgPVI0yLJWmNGUFQajRsFZwKwSyiTuu2mOsN3ad7ig+Vv/ZChVB96eD4kpIrpxMipD9LMN8cg+IahgLJwkGuyBU3NbVnCsZyGjropsqw8bN7UUzNhbrJdD8BnMCcEajDBhl9I6PA==
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)(376002)(396003)(136003)(39860400002)(366004)(9326002)(64756008)(8936002)(76116006)(4326008)(186003)(71200400001)(66946007)(83380400001)(52536014)(2906002)(66476007)(966005)(66446008)(478600001)(33656002)(110136005)(55016002)(15650500001)(7696005)(166002)(4743002)(8676002)(316002)(6506007)(66574015)(30864003)(53546011)(86362001)(9686003)(66556008)(5660300002)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?a/BVLkwmM7rE8TmCkCbSwOOt6vYyd3zP6N3FBAxUfyTLGV0FaUfyknLkn8Jo?= =?us-ascii?Q?rQp0uQtosHARm0PsaIWFu/QqFXveHPDKl+sJsXPRbSZx7/oxDDceUJInWAjM?= =?us-ascii?Q?FFY61dKqdbpZAMnfiWiWFFTniEXTkgaoH9ooR8G24BZjBKdinpkdUUfM2gDU?= =?us-ascii?Q?0ZAADlrsG1mSR9WrLD83P8I9G3gYOzg6QXJmREuuoNE+gyuHimIWukmSV14p?= =?us-ascii?Q?Af22zhCqoWnwwTfbLYhvv+GNSYeZASBnNllU/rCDcRv2BgvP2HKUi1faazGj?= =?us-ascii?Q?9PZuBC+0cBlrjHYqijx6mJSNmmA4OSOviYARjoyh57WTDY0/FhXX0c+96X0a?= =?us-ascii?Q?SIR+9rsxVqtEejxusPjmrehHzP129blHr4Dwn1o+WRixV1LRAmWR0Dy5lX9A?= =?us-ascii?Q?19I2ABdQ5H2vlmKqZPAvV7rXd+vlJY3CPZfopEhP8kECPfIXUGFt9Kociqv4?= =?us-ascii?Q?lFzLq3hk9bMy2NhmeQ18/Nb0tsIODAp5jDynNplPhXjiJLNrZ3aGkmwcHQwz?= =?us-ascii?Q?6YphHoiGsSTw0tLK4AuRnfI5NcqAjf6rq3tHfhDCpKMEFoTAJAgnQnXcRZbz?= =?us-ascii?Q?5wME9QU/DG7VQ1PjrlSBLjjtBQyDGpD5BW2CTQ2Zp2I1x7fQw4okduSYisAO?= =?us-ascii?Q?uqOy2Sem3AE/EEU3RWGN2UvGUGwGYnmGXk0qmStm1GOvg6xyTlbgfb8+USzP?= =?us-ascii?Q?3iXPInEANjL6wiI67C4AKCZQlr+fqLdJI4jbs5Vc9FASnTrVfQfsU9hp/V/O?= =?us-ascii?Q?2So5je7TsWV5EHVFhTNbEJE6h2nN4MKe6PI/OSP55Yv5LKxlPYjntESn9d4Q?= =?us-ascii?Q?d5Yj45igR4rg9NDoNwt1DSaAjGBGr0zaSJFIc9Ag433NrLvWK/gkJPj45d0S?= =?us-ascii?Q?L8janyQwqnfR9AEReyNuknyCT4oQVhilTryBCMjvJu8fcHmn6YDc/tYVJHku?= =?us-ascii?Q?mpCuYDP+TUPIH0K4qgx84QVasApTQsRyQrJknuXGicwyMt20q9O43J+3iXTE?= =?us-ascii?Q?ZGpPTMBQAEqMQBpMsq/Xqr8r1cT1ISFbWpQMHKuGGQpsfrhXDFySUrJAA72x?= =?us-ascii?Q?iw/IoTAOvYJLG8Vi9aZgTR28FZi/C+H0vfsUqk/GtvQ6ciF26u+pkQDmVrzG?= =?us-ascii?Q?dksVH25HLz9udfTrnXNaudibQsVpd8xJ1nOx2G5f5yL/72qHfdanLQ4JPBHt?= =?us-ascii?Q?IgwzLLkZvSoS0HmDm57LM0CIodtr2S+pWxCuvThADSDeSun//t/0NdmuBQLC?= =?us-ascii?Q?/lhCDXYSqjLsjHcM22ElYVVOrT4AswvmhgLrQin8O8HGJzVR6fmPE5uhqPJZ?= =?us-ascii?Q?Tz3VvgVLWn4sCNook//5nZp3QMgUdFGTrhS0BRAdOoItxIJPLDAYRu2kIrnv?= =?us-ascii?Q?s1KBupyOTSHue+3JOQclg0SgVICh?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45702B002BCB9BD49740DE78C16F9MW3PR11MB4570namp_"
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: 3850806f-1197-456d-9d62-08d8e57de4be
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2021 17:40:14.4016 (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: mK4jXHQQKxTu847kIT+luZT4mElW3tppQ7w0Slm1kWqpHzE7DX5jZFNdeZ9mwCEVyJ2nojuhW4MW0Tn/+UWPgw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4761
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KtwWTK7ADT4Wy5a9Jids1-kCwv0>
Subject: Re: [Idr] Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt
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: Fri, 12 Mar 2021 17:40:33 -0000

Hi Sue,

The corresponding IGP extensions are in https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

I will connect next week to perhaps better understand your comments.

Thanks,
Ketan

From: Susan Hares <shares@ndzh.com>
Sent: 12 March 2021 22:55
To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; idr@ietf.org
Cc: draft-ietf-idr-bgpls-srv6-ext@ietf.org
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt

Ketan:

If you are using the IGP behavior with all of the behaviors listed in table 10.2.1 then the Haibo's comment applies, you must have text that indicates how you will use the TLVs to handle these behaviors.

Is there an LSR document that handles the same values?   If you could check with Acee, to see if he has any ideas that might.  I'll check with Jeff, Keyur, and Alvaro on this text as well.

I think I need to clear issue 5 before I attack issue 9.

I was hoping this was an editorial issue, but it is a bit more.  It is better to clear the issue now before we put the draft on Alvaro's queue.

Sue


From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Friday, March 12, 2021 11:46 AM
To: Susan Hares; idr@ietf.org<mailto:idr@ietf.org>
Cc: draft-ietf-idr-bgpls-srv6-ext@ietf.org<mailto:draft-ietf-idr-bgpls-srv6-ext@ietf.org>
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt

Hi Sue,

Please check inline below with [KT3]

From: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Sent: 12 March 2021 22:05
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; idr@ietf.org<mailto:idr@ietf.org>
Cc: draft-ietf-idr-bgpls-srv6-ext@ietf.org<mailto:draft-ietf-idr-bgpls-srv6-ext@ietf.org>
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt

Ketan:

We'll consider item 1 closed, and you will delete the references to draft-ietf-bess-srv6-services.
[KT3] Ack

Please review my response to issue 5.  I think I need to understand issue 5, before I review the mail list for issues 9.

We're getting closer.

Sue

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Friday, March 12, 2021 9:58 AM
To: Susan Hares; idr@ietf.org<mailto:idr@ietf.org>
Cc: draft-ietf-idr-bgpls-srv6-ext@ietf.org<mailto:draft-ietf-idr-bgpls-srv6-ext@ietf.org>
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt

Hi Sue,

Please check inline below.

From: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Sent: 12 March 2021 18:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; idr@ietf.org<mailto:idr@ietf.org>
Cc: draft-ietf-idr-bgpls-srv6-ext@ietf.org<mailto:draft-ietf-idr-bgpls-srv6-ext@ietf.org>
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt

Ketan:

I'm pleased to see we have agreement on all issues except issues 1, 5, and 9.  With draft-06.txt, I consider those issues closed.  If you are agreed, then I'll delete the text regarding those.

On the issues remaining, 1, 5, and 9:

Issue 1: reference to draft-ietf-bess-srv6-services

You stated that "BESS BGP SRv6 draft is about extensions to BGP address families that are unrelated to this BGP-LS specification",

If this is true, why are you including this text in this draft?   If you feel it is critical to the draft, then I will go back to the argument regarding draft-ietf-bess-srv6-services.
[KT] I will remove the informative reference to the BESS BGP SRv6 draft if that is going to help clear the confusion.

Great - we'll consider this closed.

Issue 5:  Unclear text

I reached out to an SR expert during this review process of this draft because I felt this text was unclear the first time in draft-ietf-idr-bgp-ls-segment-routing-ext-16.

[KT] For the record, the text is identical for what we have out for publication for BGP-LS for SR-MPLS : https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.2.2

I have re-read the section again this morning.  The sentence below
could be clarified by indicating which of the Endpoint behaviors in
RFC8986 section 4 this applies to.

Old text/The SRv6 LAN End.X SID TLV allows a node to announce SRv6 SID
corresponding to behaviors like END.X [RFC8986] for its adjacencies
to all other (i.e. non-DIS or non-DR) nodes attached to the LAN in a
single instance of the BGP-LS Link NLRI./

If you mean only to use this on IGP agencies, then please state which of the
SRv6 SID behaviors it applies to.   If you declare BGP adjacencies
via direct connect out of scope at this point,  you can state this point.

[sue] Maybe a higher level question is key.
Why did you say "like End.X"  rather than "End.X"?
Were you implying another set of behaviors or just the one listed in section 2.
[KT3] Since the TLV allows encoding of the behavior, and as described in section 2, it can be used to advertise SIDs with behaviors like End.X that are associated with the link. We have multiple variants of End.X behavior as indicated in https://datatracker.ietf.org/doc/html/rfc8986#section-10.2.2. Hope that clarifies.

Thanks,
Ketan

[KT] The SRv6 LAN End.X SID TLV is only applicable for IGPs.
[Sue] This was clear in the RFC8986 text.
Hence - I'm trying to find what "like End.X" means.

The RFC8986 behavior is the same End.X and the SID is advertised via SRv6 End.X SID TLV for adjacencies corresponding to the DIS (ISIS) or DR (OSPF) and using SRv6 LAN End.X SID TLV for other non-DIS/non-DR routers. This is specifically mentioned in Section 2 where all these TLVs are introduced briefly.

[ok:  I begin to see you have the following specific use cases.

   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)

   o  MSD types introduced for SRv6 are advertised (Section 4.3) using
      the Link MSD TLV specified in [RFC8814].

The phrase "like End.X" implies there are more.
If these are the only phrases, then modify "like End.X" to "End.X"
In section 4.1

If the text exists in RFC8986, then you can simply refer to it.
[KT] RFC8986 does not get into IGP specifics and these aspects are covered by the respective IGP SRv6 specifications for which we already have the references.
[sue] If you are just specifying "End.X", I can agree to this.

On issue 9, I'll review the list information to see if I can provide further details.
[KT] Thanks - I will wait for the closure on this before posting the update.

Thanks,
Ketan

Cheers, Sue

Original messages
From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Monday, March 8, 2021 3:31 PM
To: Susan Hares; idr@ietf.org<mailto:idr@ietf.org>
Cc: draft-ietf-idr-bgpls-srv6-ext@ietf.org<mailto:draft-ietf-idr-bgpls-srv6-ext@ietf.org>
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt

Hi Sue and Haibo,

Thanks for your review. We've uploaded a new version of the draft to address most of your comments below:

https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-srv6-ext-06.txt

Please check inline for detail responses.
[snip]
=============
Issue 5:
Location: section 4.2, page 9, paragraph 1
Status: Major
Change: Mandatory to improve text

Reviewers: [Haibo Wang and Susan Hares]
 Old/Text chapter 4.2 SRv6 LAN End.X SID TLV.

   For a LAN interface, normally an IGP node only announces its
   adjacency to the IS-IS pseudo-node (or the equivalent OSPF DR).  The
   SRv6 LAN End.X SID TLV allows a node to announce SRv6 SID
   corresponding to behaviors like END.X
   [I-D.ietf-spring-srv6-network-programming] for its adjacencies to all
   other (i.e. non-DIS or non-DR) nodes attached to the LAN in a single
   instance of the BGP-LS Link NLRI.  Without this TLV, multiple BGP-LS
   Link NLRI would need to be originated for each additional adjacency
   in order to advertise the SRv6 End.X SID TLVs for these neighbor
   adjacencies.
/
[KT] For the record, the text is identical for what we have out for publication for BGP-LS for SR-MPLS : https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.2.2

Hares Comments: This paragraph is unclear.  It needs to be rewritten.
[WangHaibo] suggests a way to approach this text:
1.  I suggest to first describe the behavior of the LAN End.X SID explicitly,
such as "each LAN End.X SID is used to specify the
cross-connect to one adjacency node attached to the LAN".
Then describe how to encode the LAN End.X SID TLVs with
the Link NLRI corresponding to the adjacency to DIS or DR.
[KT] It is not the purpose of the BGP-LS specification to describe this and hence we have reference to the individual IGP specifications in the very next paragraph.

==========

Snip
======
Issue 9:
Location: 2. SRv6 SID NLRI
Status: Major
Changes: Some textual change is mandatory
Problem:
    [Wang Habio comments]
   Now the BGP EPE Peer Node info is advertised with SRv6 SID NLRI, it cause[s] some disadvantages compared to SR-MPLE EPE.
   First, the number of NLRIs needed for SRv6 EPE may be more than MPLS EPE. This is because the NLRI's key is SRv6 SID, but for one EPE Peer node, there may be multiple SIDs, such as End.x with PSP, End.x with USD etc.
   Second, with MPLS EPE, for a direct EBGP Peer, only one NLRI is needed to advertise the link and its Peer node SID, link attributes.  But with the current method for SRv6 EPE, at least two NLRIs are needed, one is the SRv6 SID NLRI for the Peer Node SID, the other is a Link NLRI with the End.X SID (the SID value may be the same while need to be advertised in different NLRIs) and link attributes..
  At current stage maybe it is not suitable to change the encoding, but I suggest to give more detail description about the behavior of advertising the SRv6 Peer node SID and the Peer adjacency SID with corresponding NLRIs for a direct peer and for a peer established on loopback.
[KT] I remember all of this has been discussed on the mailer a few times already (and even offline) during the life of the document in the WG.

[Hares] Solution possibilities:
a) provide text in section 6 prior to NLRI format
b) create section in manageability section providing more details

If have questions on this request for clarifying information,
send email to me, Haibo, or the list.
[KT] I am not able to fully understand what is being asked here and I guess we need further discussion. Is there some text that you have in mind that you can propose?

=========
Issue 10:
Status: Major
Change: Mandatory
Location: 7.1, bullet point that starts "Endpoint Behavior"

Old text/section 9.2 of [I-D.ietf-spring-srv6-network-programming]/
New text / section 10.2 of [I-D.ietf-spring-srv6-network-programming]/
[KT] Ack

========
Issue 11: page 17, Figure 13
Problem: reserved fields
Type: Minor
Status: Recommended
Old Text/
Location:
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P|         |
    +-+-+-+-+-+-+-+-+

            Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format

/
NewText/
Location:
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+

            Figure 13: SRv6 BGP Peer Node SID TLV Flags Format
/
[KT] Ack

[Hares comment: Clearly specifying Reserved Fields in figure helps the reader.
[KT] Ack

[Wang Haibo comment:]
   [comment]As Figure 13 is about the Flags of SRv6 BGP Peer Node SID TLV, its name may be changed to SRv6 BGP Peer Node SID TLV Flags Format
[KT] We have flags in most TLVs and I don't see the point of prefixing the TLV name with each of them.

==========
Location: Section 12:  Manageability section
Praise:
Thank you for mentioning the sematic or content checking is left to the consumer of the BGP-LS information.
============

Thanks,
Ketan