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 14:58 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 9ACFB3A1264; Fri, 12 Mar 2021 06:58:32 -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=Kup0dGOh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Wy5A2AyB
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 K7zhQR5NqYdZ; Fri, 12 Mar 2021 06:58:29 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27DF3A1164; Fri, 12 Mar 2021 06:58:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=92808; q=dns/txt; s=iport; t=1615561105; x=1616770705; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0yw8xRTjgJG1ZEyLb38qQdeUrcekd8Ta77od+FkPpRc=; b=Kup0dGOhnzERBi3WNYvGvJMyJ7OW6IRI/FhVxWZM7whDXJ2OUih3HTHU WsKNg/hzk+3mxRkSXsa4PyW0hvnllcroIeaRysYHFt/iJq8G2Kfk+e9AW sFjjpmB5a58UnmUtOGw69BpVl14q3L40yndIcQTdyActsJf2ha3Y7qy/+ E=;
X-IPAS-Result: A0A7AAAlgEtgmJ1dJa1aGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBQIFPgSMwIy59WjYxiAkDhTmIQAOBB44YigyBQoERA1QLAQEBDQEBKggCBAEBgTeDFgKBdAIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DYZEAQEBAQMaExMBASkJBQEPAgEIDgMEAQEhAQYHMhQJCAEBBAENBQgRAoJVAYF+VwMvAQ6hUQKKHnSBNIMEAQEGgUdBgw0YghMDBoE5gnaEB4ZGJhyBSkKBEAEBQoIjNT5pgXcBAQIBgScBEgEjJAYBCYMUgiuBWAERFAg+BgEBDQEuGwsEFA4pBgIgAi4KIQoTLAgNBQwBERYCFwYFPpAtDguKdzCMNJBGgQsKgwGEMYUYhwyMBIM9iluGAo0lglGUcoINiUKSHA4YhD0CAgICBAUCDgEBBoFrIWlwcBU7gmlQFwINVo1JDAUICRSDOYUUhUVzAgE1AgYKAQEDCXyTBAEB
IronPort-PHdr: A9a23:ktO/CRRFWZBn9oyh576ZSSyZP9pso03LVj590bIulq5Of6K//p/rI E3Y47B3gUTUWZnAg9pCh/jW9avnXD9I7ZWAtSUEd5pBH18AhN4NlgMtSMiCFQXgLfHsYiB7e aYKVFJs83yhd0QAHsH4ag7Urm+yqzUVH0a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+I Q/wox/Ws5wdgJBpLeA6zR6aykY=
IronPort-HdrOrdr: A9a23:lHotMqgPmHmFRDXvmSQPogvl6nBQX4hx3DAbvn1ZSRFFG/Gwv/ uF2NwGyB75jysQUnk8mdaGfJKNW2/Y6IQd2+gsFJ+Ydk3DtHGzJI9vqbHjzTrpBjHk+odmu5 tIW5NVTOf9BV0St6nHySGzGdo43Z2j+Kenme/Rwx5WPH5XQotLhj0JbTqzOEtwWQVAGN4dHJ 2T+sJIq1ObCAoqR+68AWQIWPWGms3TmPvdEFA7LjMEyC3LtzOn77bmDwOVty1/bxpjyaovmF K16DDRyb6kt5iAu3rh/k/Vq69bgd7wjuZEbfb89vQ9DhXJpkKWaJ96W7uE1QpF4d2HzFoxit HDr1MBEq1ImgnsV1q4qxfsxAXsuQxGgxSJpDPo4gqAneXDSD03EMZHj45CGyGplnYIhs1206 5AwguixvxqJC7Ahyj06pzpUBxnhyOP0AIfuNMTlHBWXM8ibqZQp+UkjTpoOaoHdRiKjLwPIa 1LNoXx9fxWeVSVYzTypW902uGhWXw1A1OvXlUCktb96UkXoFlJi28jgOAPlHYJ85wwD7Ne4f 7fD6hunLZSCucLcKNGAvsbS8ffMB2PfTv8dEapZXj3HqAOPHzA77Tt5q8u2e2scJsUiLw/hY rGS1EdkWIpYUrhBYmv0fRwg1LwaVT4eQ6o5tBV5pB/tLG5bqHsKze/RFcnlNblrO4YBsHdRv avKJNbC/LuNgLVaMJ09jy7f6MXBWgVUcUTtNp+cUmJuNj3JorjsfGecPu7HsurLR8UHkfERl cTVjn6I8tNqmqxXGXjvRTXU3TxPkj2/Zd6FrnG7/EeobJ9cLFkg0wwsxCU98uLITpNvugdZ0 1lOo7qlau9uC2x5mbH72JgPxJHFUZL6LD8U3dHzDV6dn/cQPImgZGyaGpS1HyIKltUVMXNCj NSoFxx5OaqNZCK3DsjDNimK2qeiHMWqBuxPs4hs5zGwf2gVoIzD54gVqA0KB7CEAZtnx127E 1ZbhUfe0PZHjTyqKmsgZAOHtvDf91kjArDG78NlVvv8WGn4eAmXD8yQiOnW8//u3deexNkwn lKt5I5rJXFszC1Mmc7iPk/KzR3GRSqKYMDKh+EaoVSkq3sYydqQw6x9GenoiB2XHb2/EMPgW GkCiuYdZjwcwdgk0Ed9Lr2+1VpcWjYRWZMUzRRtI1wEnmugAco7caCerez32yNalEL3+EaN3 XfbSEPJx51rurHpyK9iXKME24ryY4pOfGYBLM/c6vL0nfoM4GQk7oadsUksapNJZTrsuURV/ iYdBLQJDTkC/kx0wj9nAdvBABk7H0lm+jvwhvr8Syx22M+G+PbJBBjS6sAK9+Rq2jiSPDg6u Qysfsl+e+xOH72cNiI1OXeaCNCMArapSquVP4zwKoky54apf92Bd3WQDHI3HZI0FE3K9r1jl oXROB+7KraMoFicsQOc0tijxYUvcXKKFFuvh39A+c4c11olXPdMt+T67fDqLYkACS61UPNEE ja9zcY8+bOXiOF27JfFrk5Jn5OblMgrHtl5+GPeuTreUqXXvAG+ED/NHCzcLVQEvfYXboRqw t3+NGOkauccTHi1AXZoDt8JeZP/g+cMLePKRPJHfQN9dqwfUmIiO+t5sW4iT/sUzu1a0gCn+ R+BAUtR9UGjiNnlZE91yi5V7f+rU0kmUZP+D0PrC+Z5qG2pGPAWVxcOQLXgp9KTSBeP3iBg8 PC6/WZ3h3GkU948IiGElxRcNFIE8URSYayLz4GE7ljgIKV
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,243,1610409600"; d="scan'208,217";a="701235704"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2021 14:58:16 +0000
Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 12CEwF7k002445 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 12 Mar 2021 14:58:15 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xbe-rcd-001.cisco.com (173.37.102.16) 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 08:58:15 -0600
Received: from xfe-aln-001.cisco.com (173.37.135.121) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Mar 2021 09:58:13 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 12 Mar 2021 08:58:13 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZF+yGKIv5ylt/2TTnlZS3QzhyVs4WxqCcMSKe/2REtQ/tF+W9MSUE531bEaV2OEfTz6jzNXdr43zn6I8radXn2k2sc0ZX/r4hW0v1Vjuo2Mm4izq+QidXWvPR4r+MeaiA5BbOSb1f1fXK5KevFR4SsJOorKTDZOwlhSJOfVUP/mg2ndH3ZIqmZlobBojgzJtQaHnA0+u59lAtsBSlr1C2FMtPAM8eJjKCGU3FOkvKzgk+8LGqA5/2R+4bXmpGTTUL3jdX/0lVPo5gT0zQ0DEiG6aGzEfYMItODL4GfcV+BkJLiS/HGWzY3cgP2vSYN5noPqFOlJGleLfSS4bJA6ozw==
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=yNg962HzAoKRD4lmNLHJ0tnKrYa2EN6naIiQeotuwdo=; b=n2f+zO8auU6volJBNPGs3GBTkJCfTnOHE55ahRfzCMSLMtn+05k39jBuKcYkpXCLvKDLORsFLftUcBfB8kCfiPiHFhoB6IUwIWXKGMKDGqsZ0emESHq7rCHw3tMb5VKqEqFbSs5l4pVro04tQtvJQBaxWY5OMlWYD/eymw3pDXY4We4aCVOVru6yupwd6UBnkONkKHycEPkkeFRyWa80jO45T/l6pT6wCMO4KOgp5VQTqQMTnHkDJUIhqxmDstDlHpYsmX9bdfDlG19TnB4PkSYxZNz9fBZHvPwYVguSQKT5eZGbG2REa3KnPwsOR84BwXn2gKxFX1iF4Er6I3/svg==
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=yNg962HzAoKRD4lmNLHJ0tnKrYa2EN6naIiQeotuwdo=; b=Wy5A2AyBB1hLNNi9N3+Ab2ehG9gclxKtEZ7ok4NkpUX+Qz4/DG1kB7kFQl2I5VaUiIIazNL2aK/iiLfEzguQrSiu24z0J4i7Qry1EPPpigb+tHgaatirIy56SFknzoxLrPYiFVYV9dweJpzCDiDaSr0K18FfGtaOHUCue6riWKw=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4585.namprd11.prod.outlook.com (2603:10b6:303:52::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Fri, 12 Mar 2021 14:58:10 +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 14:58:10 +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+dEg
Date: Fri, 12 Mar 2021 14:58:09 +0000
Message-ID: <MW3PR11MB45702E32F8A2F644261F659DC16F9@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <00b901d7173e$bb21ba80$31652f80$@ndzh.com>
In-Reply-To: <00b901d7173e$bb21ba80$31652f80$@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: e28267ba-0a3d-4bfa-be75-08d8e567408c
x-ms-traffictypediagnostic: MW3PR11MB4585:
x-microsoft-antispam-prvs: <MW3PR11MB458592602800CB749B648F53C16F9@MW3PR11MB4585.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: 6LdHwfOx5K8uaFLwDXo4KuuhcWJMDbaRuOyPfrpUKO1alQWQgilXbkxZuMoRjBTvctkAC5KPo8GCVrttBl3mOekv19CGhJRE+FhKItFtR7T5TmGlizoSeXXdJZ1WRksED1NshC3F3bHkPhgpjPE50pz74pSZ5AZ1LOGR1GjKb2tdam0EqFM2tPV1FxGo36LFSlORbwKZD++kXpIvdtyyn/hMuvQyx+NOW/Thw6b/P3KTSSLsh81hP8GiY3aGY/VrAZXoMOwWBQ2QbnhVs0NtSEmIXwUyYllmJTPM7gcRApFRebn3/zL8T+n4HwOFulhyqMd0mr6V10hUHOp4i0bMROW9NVUeJO3wcBCCQ+Cxd4ppU2pa5lCeVzmxTqJ0Iub+LNLAouInlfnXns4UB4VOvCwZuJJHVNdkzx7fN8Ezxy6fX+CQ9tzvKIjU3MBw6+Y+KSX2T9QaOeDgudCjPKqvKy8r5Nye2Pw2smCcd/7O6BsqFfh14EQ+DHeBvf73ZnVnyTFTvrrI6qlrqFBfTBUS9gZVGaFwvahpZy6++lvLq3+oH8XM6XlvxWq1/fWsxBdWez2c2MTts1xpVORg4MmNNUjcXtWBbViFeXSWIsd2g9FCIeFzp2EziSbgwwOo1Ar/UemIvMLQQlhCCpI2XqbKgA==
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)(346002)(376002)(136003)(39860400002)(396003)(53546011)(6506007)(186003)(2906002)(33656002)(15650500001)(9326002)(8676002)(7696005)(8936002)(9686003)(86362001)(478600001)(316002)(110136005)(4743002)(4326008)(966005)(55016002)(66446008)(66946007)(66476007)(64756008)(66556008)(76116006)(83380400001)(71200400001)(166002)(5660300002)(52536014)(30864003)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: jbqR360sPomFnf7yzH187SB1wMxn8SQmYiSeh4fgloQZytnQs7GIV/7+Z3p2UCjvlFdxkOmwxG2CYJcrh82fd0MmvSogNyU9z5af3vtXo4NeexTB6X1xcOtJyJUYsiiqcZip9uaF0e3r/+ju7Z/ffFm4JSExu1Jx+gCIvJnoSvjO5wEGRuh5uWJWnUv4frJsyurqaVj5enMneFEYlrD5UQE8nJW5NlQdQXOGrcu0PJu+a53gwEDnYCsrgD7XMNFzJHW5NSb+Zm0y7qM4g2oFFkJS1fMUBy2G3wG4HHcK2V06ZmwEnSOpvXVsW0qeZXRno9TXOC6afp71Vn6xM/LvaczoOTcQFe7nhKZQ+7VZIrKuSozKpnpdqqSixlSZ21hIHBT9mZF3qtyU4/fmelUck4vP75GFzdMe5IBIasU8cDiR0GB4H5kbq1eD/85W9DCcfT5M3VOBmKibcQ5Dogurj6A4BGcfyXIQHIOqEPKKNxfRfI+4sNS3qJBLDjYIiCuqiny2+JSnatkJG0V/whdj6jH7Jaf1QXV270HJ7W84mbJmh0LzZN21JtqC/MuD62vz6QHUuFIrK0dpxcLBTe78tWgtT/oIEwGN14T5rKIVDWeoMH/t6Xuouspce0viIBYVdT5ujXADXqAQHcorr0Jk2L4sTur0+vrLzOqidwLebdGyW4cCPJrt1dE74R5gtlcFIf+Y9Y5FgYfXARtMyLJGJTFBo+dnwnz/oRtjE54Lub9m4Yzfuo1qLqoFER8Sccv27mO74eM6f65mWggLLWwVYcNRJRKjuspeEVA/LLGxrQREbKfwMcz7KqLGNkz/Jx25kMrv5F9iZ370IE9cVOxLgWlHa489Aztl00+DvgGkOCvL3RdrLoUBFYXPxvdo5AB3dHTc74qEtQbUjho4YPUK956ujlH++Ny54XZaSBI1kmwMH0Ce4j1UjKNkKEbGjLCWZYnFETacO7aDlrwKD7iUg8h2aNmFj5SHB0Tq2L2BQZ8fKimoP/tIzdAupaYvWw6kSBojlpNCRa8wns47ZZbiqlwQxC0tPp1/OACjmPlvw3crqhC04Gy+fbIihCDT3xTlIfGBvkSdSGASzmKwz7JV9ZEAo9Xrsd7HxU73tExzDXTn0pxrc/9a/lGJdCBCTnJGMxNAJUaDUQsUw+oA7WQ5399aVSaTaVnnapMTwdLDC+HGDKiRiYS198nrTcQ8rj/9KZpexVDZFouyr4wElTell8pGvDxwu8syPQ9RI3r2GtwYcdUbRb0G33Khb0ZYk8ZOdDbE2luVC1PrHOd74+CxObEpy12iE9X88eaoLLTJnYKUrKmusRFsg76W9OEc3uOGtxLtRhaTiJ7JudLqfr8wasN2tk5wt/jR5hagc707DnKKUL12e7DRlghA1dFPARJG
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45702E32F8A2F644261F659DC16F9MW3PR11MB4570namp_"
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: e28267ba-0a3d-4bfa-be75-08d8e567408c
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2021 14:58:09.8610 (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: lq4VHRI7ZkD+5VGJmBauVah4ET1kOcg6CIsoO6vuHf6OwN8/sHiM9mTe8AG/XlBUZw3+NquKpL//9Q1i8BJlaA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4585
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RCuTHv6V9_vBI2IK_UsZFQvGnj8>
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 14:58:39 -0000
Hi Sue, Please check inline below. From: Susan Hares <shares@ndzh.com> Sent: 12 March 2021 18:24 To: Ketan Talaulikar (ketant) <ketant@cisco.com>; 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: 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. 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. [KT] The SRv6 LAN End.X SID TLV is only applicable for IGPs. 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. 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. 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. From: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> Sent: 20 February 2021 01:37 To: 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>; Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> Subject: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt Guarav, Ketan, Fils, Mach, Daniel, Bruno: First of all thank you for your hard work on refining draft-ietf-idr-bgpls-srv6-ext-05.txt. I'm glad to have this draft in the SRv6 family. This shepherd report is a combination of my review and a review done by Haibo Wang. As you recall, I asked for SR-Reviews to review SR drafts in addition to the document shepherds. I've indicated Haibo's comments in my review. I appreciate his help in reviewing this IDR draft. I'm working this weekend in case you want me to review any changes before the draft deadline on Monday. Cheers, Sue ============ Issues are marked with levels: major or minor Resolution is marked as: Mandatory or recommended Issue #1: ======== Location: Section 1: paragraph 3, sentence Issue: Major Change: Mandatory Original Text: /BGP (I-D.ietf.bess-srv6-services)) has been extended to advertise some of these SRV6 SIDs and SRv6-related information./ Problem description: The reference to this bess draft means that you must support all the features within the draft. Specifically, if you are indicating support for the EVPN sections of this draft you are more likely to hit the issues described in section 4.9 of draft-ietf-idr-rfc7752bis-05.txt. [KT] The reference to the BGP SRv6 draft in BESS is informational only. It is not related to section 4.9 of RFC7752-bis since that is applicable only for link-state IGP protocols. If you wish to keep this text, you have two options: Option 1) Replace RFC7752 references with RFC7752bis and make appropriate changes Or Option 2) Keep dependency on RFC7752 and change the last paragraph of section 10. For option 2, I provide you with sample text change below. This text is just a example. Old Text/The extensions, specified in this document, do not introduce any new configuration or monitoring aspects in BGP or BGP-LS other than discussed in [RFC7752]./ New text:/The extensions, specified in this document, do not introduce any new configuration, monitoring or error handle aspects of BGP or BGP-LS other than those discussed in [RFC7752] and [RFC7752bis]. In some use cases for topologies that might be used for draft-ietf-bess-srv6-services EVPN, the error handling in [RFC7752bis] section 4.9 may be necessary to handle the combination of unreachable IGP nodes, BGP-LS with certain BGP Peer topologies, and service requirements of VPN applications./ [KT] The BESS BGP SRv6 draft is about extensions to BGP address families that are unrelated to this BGP-LS specification. =============================================================== Issue 2: Location: Section 3.1, page 6, figure 2 What changes: Addition to field to clearly show Reserved fields Issue: minor Change: Recommended Problem: Text unclear without reserve word Old text/ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |O| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / New text/ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [KT] Ack ========================================= Issue 3: Location: Section 4.1, page 8, bullet beginning "Endpoint Behavior" Issue: Major Change: Mandatory Problem: section 9 is security considerations in [draft-ietf-spring-srv6-network-programming] Perhaps you mean section 4 (SR EndPoint descriptions) or section 10.2 or 10.2.1 with the Initial registrations for SRv6 Endpoint Behaviors. Old Text: /End point Behavior: 2 octet field. The Endpoint Behavior code Point for this SRV6 SID is defined in section 9.2 of [I-D.ietf-spring-srv6-network-programming] / New Text /End point Behavior: 2 octet field. The Endpoint Behavior code Point for this SRV6 SID is defined in section 10.2 of [I-D.ietf-spring-srv6-network-programming] / [KT] Ack ======================= Issue 4: Location: Section 4.2, figure 4, page 8 Type: minor Status: Recommended Old-Text/ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|S|P| | +-+-+-+-+-+-+-+-+ / New-Text/ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|S|P| Reserved| +-+-+-+-+-+-+-+-+ / [KT] Ack ============= 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. ========== Issue 6: Location: section 4.2., p. 10, bullet beginning EndPoint Behavior Issue: Major Change: Mandatory Problem: Section 9 is in the security section. If you mean section 10.2, then the text change would be 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 7: Location: section 4.2, figure 6 Issue: Minor Problem: figure unclear without reserved words Change: Recommended Old text: / 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|S|P| | +-+-+-+-+-+-+-+-+ / New text:/ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|S|P| Reserved| +-+-+-+-+-+-+-+-+ [KT] Ack ======== Issue 8: Location: section 5.1, figure 8 Issue: Minor Problem: figure unclear without reserved words Change: Recommended Old text: / 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |D| | +-+-+-+-+-+-+-+-+ New text:/ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |D| Reserved | +-+-+-+-+-+-+-+-+ [KT] Ack ====== 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
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Susan Hares
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Ketan Talaulikar (ketant)
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Susan Hares
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Ketan Talaulikar (ketant)
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Susan Hares
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Ketan Talaulikar (ketant)
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Ketan Talaulikar (ketant)
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Ketan Talaulikar (ketant)