Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Thu, 29 April 2021 08:27 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD3F3A3598; Thu, 29 Apr 2021 01:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.917
X-Spam-Level:
X-Spam-Status: No, score=-11.917 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_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KcmUObk5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lLZCpli2
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 abb9cLKZAc6c; Thu, 29 Apr 2021 01:26:57 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD7E3A3597; Thu, 29 Apr 2021 01:26:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39236; q=dns/txt; s=iport; t=1619684817; x=1620894417; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AD1pDiINHMgA2yvgxQSb1Q6mJAvOwTeOlA74GtztPuc=; b=KcmUObk5sNXqnSirSsWtF2G72oNFypO7awsOOlqeaWhMFk1m1TpMe67M kcF4jd8TpSBUy4h3JGlZDk6R/MHbl4LWh0Zv+b7QAqLU7CgGGR1SVYfsW /dw+xcXDtSO7Arjqv0O38escA/0JEVvIWZRdbXVle4UswpyzXgyBn7uf6 c=;
X-IPAS-Result: =?us-ascii?q?A0AaAACGbIpg/4UNJK1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBggUDAQEBAQsBgSIwIwYoB3daNjELhDmDSAOFOYhxA5lMgS4Ug?= =?us-ascii?q?REDVAsBAQENAQEdAQwIAgQBAYQMRAIXgWQCJTYHDgIEAQEBAwIDAQEBAQEFA?= =?us-ascii?q?QEBAgEGBHEThVANhkQBAQEEAQEbBgoTAQEsCwEPAgEIEQEDAQEhBwMCAgIlC?= =?us-ascii?q?xQDBggBAQQBDQUIgmqBflcDLwEOnVoCih96gTKBAYIEAQEGBASBSEGDJBiCE?= =?us-ascii?q?wMGgToBgniECQEBhlMnHIFJQoEUAUOBX4EAPoJgAQECAYEjBQESASMMGAcJg?= =?us-ascii?q?mE2giuBWS0+BwFfAwQYChARDgJbIF4EBy4ZBhoaD5BTGYMxh3iNCZBWgRQKg?= =?us-ascii?q?xCJdIcjjCIQg1SLBoYbjUeCXZUqghaJZ5J1hGcCAgICBAUCDgEBBoFbBi1pc?= =?us-ascii?q?HAVO4JpUBcCDo4fDBaBAgEHgkSFFIVJcwIBNQIGAQkBAQMJfIsDAYEPAQE?=
IronPort-PHdr: A9a23:XaBX1BdP+zg6J4O9EAAv0VX2lGM/QYqcDmYuwpM6l7JDdLii9J3+P UvZoO9gl0LNQZ6zw/1BguvS9avnXD9I7ZWAtSUEd5pBH18AhN4NlgMtSMiCFQXgLfHsYiB7e aYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHRCsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57I Bis6wvLscxDiop5IaF3wRzM8RN1
IronPort-HdrOrdr: A9a23:SKVhK6EYJu/zhaNopLqFupXXdLJzesId70hD6mlYcjYQWtCEls yogfQQ3QL1jjFUY307hdWcIsC7IE/03aVepa0cJ62rUgWjgmunK4l+8ZDvqgePJwTXzcQY76 tpdsFFZ+HYJVJxgd/mpCyxFNg9yNeKmZrY+tv25V0Fd3AMV4hL6QBlBgGHVmh/QwdbDZQ0fa DsmPZvjTymZHgRc4CHFmAINtKz6eHjubDHRVo9BxAh4BSTlj/A0t7HOjWRwxt2aUI1/Z4M6m 7A+jaJg5mLk/b+8RPE0n+W0pI+oqqc9vJmJOihzvcYMS/tjAHAXvUhZ5SnsCouqO+irHYG+e O82SsIBMh453PPcmzdm3KEsGOMvEdMmh3f4GSVjnf5rcvySChSMbs9uatibhDb50A81esMtp 5j4mODu5JbSTPGkSjtjuK4Ly1Cq0uurXIu1dMUlnxUOLFuEYN5kIp3xjIwLL4wWAbBrKw3Gu hnC8/RoNxMd0mBUnzftm5zhPSxQ3UaBH69Mwg/k/3Q9wITsGFyzkMeysBatGwH7ogBR55N4P mBGrh0lYtJUtQdYctGdaQ8aPryLlaIbQPHMWqUL1iiProAIWjxp5n+56hww+22ZpoSzt8XlI 7aWF1V8U4+EnieS/Gm7dluyFTgUW+9VTPixoV1/J5ioIDxQ7LtLGmNU1Yrn8y8o+gOA8HSVv qpUagmR8PLHC/LI8Jkzgf+U55dJT01S8sOoOs2XFqIv4bKJ+TRx6vmWceWAICoPScvW2v5DH dGdiP0Pt984keiXWK9hBDQXnjqa1Hu5J4YKtmdw8EjjKw2cqFcuAkcjlq0ouuRLydZj6AwdE xiZLX9kq26omGy9X3S73pgPwdcCko92sSkb1p64Ssxd2/ke7cKvNuSPUpI2mGcGxN5R8TKVB JEq09v4qKxJZyIzSUkA9aqW1jq1kc7lTavddMxi6eD7cDqdtcEFZ4gQrV2DhiOPQdygxxWpG BKbxIkSkfTGij1s7isiIUZCYjkBoFBqTbuBfQRiHrE8W2AuMkkRxIgLk+TeP/SpTxreh15qR la9bQFjL+JhDC1QFFP8NgQARlrc2SYALVPEQKfQp5b84qbIz1YfCOtmSGQjQ01dy7M8Ugf71 aRcBG8SLXsHkdXvGxe3+LR1G5MMk+Zf052dxlBwNdAPGzbp3d+1vKKbKKv022XLkAP2P0ZLS utW0pgHip+g9+wzxKbgzCECDEvwYgvJPXUCPA5f6jUwW7FEvzEqYgWW/tV9o1iLtbgr6sCVv +eYRacKFrDeqgU8h3QonYuIy9vrnY41fvuxR3+9WC9mHoyG+DbLlgjR7YVJbinniLZbufN1J VyltQuu+Ssdm33d96d0KnSKydZNQm7mx/Bc8g47ZRP+a4ivrp6GJfWFTPOyXFcxR07aMP5jl kXTqh36K3IU7UfM/A6amZc5B4khd6PJEwkvkjtDugycUokgnXbM9mKioC44YYHEwmEvk/9KF Of+ypS87PZRCOFz6cdEL91LmJMakQwgU4Ss9+qZsnVEkGteO5C9lbhbSP4f79ZVaSfGbIf6h x9+MqFmueLdyz+nADc1AELVp5m4iKiW4e1BgnJBOtDt9q9Ml6IirGx4MGygCzsIAHLIngwlM lAbwgIcs9HijM+l4U53Si5V7zvrise4i5jyCAikkSox5Ov72jaF1xXKAHVgp1ZWj9IL3iD5P 61htSwxTD6+zhK2Z7KCUdWcJVPArErP/rKExs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,258,1613433600"; d="scan'208,217";a="690104648"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2021 08:26:56 +0000
Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 13T8QtFo016094 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 29 Apr 2021 08:26:56 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Thu, 29 Apr 2021 03:26:55 -0500
Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 29 Apr 2021 04:26:54 -0400
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 29 Apr 2021 03:26:54 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k16kNU+50QeWlqrAzuk7Tn3zG/2L4qTFx5vEUCMgm5aqd0KBHo1mhtHvXVqn25xKedE2jTxJk/0tjDt+QLoQhNdV0ytqVnuAN6BMCwqQJ2AbA+njXg3lUzTD5uoHxUBy4F98xlbjkmPZv/BoOYXtZv1THAbmE5hZwJdfakgpOPjqPD6Sze2zDXfFzK9hOMTPiIXrakA9e8t9uQklV3r/T+04qKWLpAqueedcW+HZmux3vOySL+q/1dVkIoUyZQBSL8Eo3yVuHKop4nG2DCG8zUmTX7Wu6n2lN7W6B/aBwtfTjHM2yylRIfJveyTWcAvr4C4hP4NLE/IMxSrBbOUxuQ==
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=AD1pDiINHMgA2yvgxQSb1Q6mJAvOwTeOlA74GtztPuc=; b=V+MmW5LlXkHKWx+4vp6b0Y2FrZVTRQ84yItKc4jiFN8AWsRtCCh5iiwn3oc2mstph0j8yL6WI8jr6qirmteKQw4NMhHumSUtssLlewgWQlS4Xj6cm28YKcQgoU3Z2u4Zsn3vIrvlP1j7GJZlQWr6MbjqO/fqfDIR9krRq9mmNqYt7roSIf2YCIBDCzpNBYEXdI+xIAt44tGUzXZAMhumZJky+4twqYSz1U9qXncjlNQ6EJkCPNY/0pp9BVCt0vVJ0ESFuzn5e6B8/MSdbiqaGmo+dcY/GlxzFtdKGiPdLMfhAJNt235PRCHhO5Qc6A7rzduVytS77lsjkhtt4P28Xg==
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=AD1pDiINHMgA2yvgxQSb1Q6mJAvOwTeOlA74GtztPuc=; b=lLZCpli2mCNCmZtq1TOcizx5Wty0VA3jAoHimVVRZHk9i3RIard93kgRG+l6EYg/jdkiMjgfBxVM5xe+P+gnAfwBqm1nxU3J96xhNwX+Y7kHxMr9chn5VL6HDX27Fp9p1d5syPDX1xP1zT9+jPF4wRJFbpmN+tHcAzb3ihS23C4=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1549.namprd11.prod.outlook.com (2603:10b6:301:c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Thu, 29 Apr 2021 08:26:53 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::592f:2e19:cf5b:a0f5]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::592f:2e19:cf5b:a0f5%5]) with mapi id 15.20.4065.027; Thu, 29 Apr 2021 08:26:53 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>, James Guichard <james.n.guichard@futurewei.com>
CC: "spring@ietf.org" <spring@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Thread-Topic: [spring] WGLC for draft-ietf-spring-segment-routing-policy
Thread-Index: AdcuvULnk99okXSERoCLmuuUCHnxwAOAoYgAAAFggFA=
Date: Thu, 29 Apr 2021 08:26:52 +0000
Message-ID: <MW3PR11MB4570B64CAD44377A56D5C0EDC15F9@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <MN2PR13MB4206EF1F6E9B1C01BDDCDD76D24D9@MN2PR13MB4206.namprd13.prod.outlook.com> <CAB75xn6mV0b6AT_6DQEGNBvhMw1bLm7Hr-X71+afe+zPMBxaPg@mail.gmail.com>
In-Reply-To: <CAB75xn6mV0b6AT_6DQEGNBvhMw1bLm7Hr-X71+afe+zPMBxaPg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 044bfa93-8199-4604-7b67-08d90ae88afe
x-ms-traffictypediagnostic: MWHPR11MB1549:
x-microsoft-antispam-prvs: <MWHPR11MB15495A169E6253120351CDE2C15F9@MWHPR11MB1549.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Mzgp4dALBok3Y5UuS272EVv53e2n/kstF+pAfd89c271i3uUJCeoQ2gwuYoHkmWBHrXqY+6lWGyHmMXtJ6bEiCtbgiWVg9AKA1RB/VStKYcICPK84D4bos5TWr1XhAuMqu5gqz/656kFnl936O6yi/A6fHOHpN0WlzRmghDibPf8mm44aW+LZSoR88o4AIyM3N0S7gSoWhOtbF4zNYW/BEyGO2YV0pDJaFFTSd9yqEoPtFM4WHmHno80XISFsJVqwWHx1eHzjKpQaYMJbhUuagKNz04h2ZY49m4tIvC6YeCfWSJe593x5NYgdonKk+1dq35TDa+sKZgaQhnWloGbokVkjumDpTBn83R9jSr4efVnC6iH8wo9VT1XIR4q5Qn8xevB7Fn33nK1Hu3aS9uFuYBb9vfcLWl1d0GOGe2RQSLVNF3xlA0Pk2qe5bte61ocSOTDUNg83oZ/PcD88IsOFcqHtshewC9kQZu0rX1ubbtAMriChnvbfOfs6KTj/3DN0RKSfT3Xbkq4L2AoT3Nna6BJlDSTSO1OzvaRz1n81keBoWOrFs63PYSnNs0CsGg8Ed3G9U73j9siHxDnxtyTZ3wkRgkjdAIVTmwUKIVyHH+Sz0/c79+ibe7LcLMatRsBuRNGqWGCWGeM/H4259CttRaz7WJI7Z52fwTZxtBoEzzWF0fhpN/M87qNrmgQ8Mfr
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)(136003)(39860400002)(396003)(346002)(376002)(66574015)(9326002)(316002)(83380400001)(122000001)(66476007)(7696005)(64756008)(55016002)(66946007)(166002)(52536014)(8676002)(33656002)(38100700002)(4326008)(66556008)(186003)(2906002)(26005)(76116006)(9686003)(86362001)(478600001)(71200400001)(966005)(53546011)(6506007)(8936002)(54906003)(5660300002)(66446008)(110136005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: LaXKwgX0XLEkFHkbjbETEF6YxyOpwyeYuRMjahTSNHe344W+nSOWWcoWE1zMmFSRJi+RLctzXpjm0nc2LGh8fEr1l/yr3Ap1nFtInMiNJSJJNMTT/DvcCRmEHzzPVwKj/a/uz07q1er1/nAE7Xe7PUzsXmwnf8WoVpOCRJX822WpWhh35uvdefax/p3z+HjRfN8fPICU/wIVhkv6INmwIfmBjgoG4pd7gs2wC4baYUOvGbnDesfw71OR2SiWlTEstbG30R//W3Y1RGVfoUJKh6rr3cQuv0sYBxy63s++dW+mV/Xj0qrfsrD9vNWCSiAAp53e1OVv1uOEdUkXX4/6VP3iqgO2V1y4mdIcjoUWS5j9KKvLhYlnRNAAA/bYdyxs3RG5G+dw47cdHDAdvUH7RvfmSRuf+dY+0WgTd7hrYoMUO+1rIWREtzBDIgh+aJzdh3dfqzTDicqtjXdG4fIN/6xRZiJGOgOXlEBKzoDQj+5L/aal2QwPkmUXrZ/re0ScO2Fgn+Jww4vkvqfHJfPrcZ7+ygz2qMSEa4D9MdbFQDx+SSSeGSUHvY6jL7LBrb4gidcNRFy/JpGySdTQNltAi9i7V2gSoLcld6NribSKzUUC/Kvw0KHW/qL+LCHSCanBYJB/C1Y6lUVB56OJyVAc9peIKTymYnYcBVmhbNNJiQNhaUPGhhfJoGFuYpv+ov7sZyou0jefxMxOo/trb5OImwBdEfUsJNz/JMIVl4Ft+To=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570B64CAD44377A56D5C0EDC15F9MW3PR11MB4570namp_"
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: 044bfa93-8199-4604-7b67-08d90ae88afe
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2021 08:26:52.8208 (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: rNbNTZ+L87y/ifZb+7rPEmw7NTTy/3e0Vo8bMiwoiHPfziHzW7JspJGsui5WqNWpp8m98msUleq9A02EjcZEvQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1549
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/pDbqDm5zP4wnay0McI67qpxYP3k>
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Apr 2021 08:27:03 -0000

Hi Dhruv,

Thanks for your detail review and great comments/feedback.

Please check inline bellow.

From: spring <spring-bounces@ietf.org> On Behalf Of Dhruv Dhody
Sent: 29 April 2021 11:51
To: James Guichard <james.n.guichard@futurewei.com>
Cc: spring@ietf.org; spring-chairs@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi WG, Authors,

Support publication. The document reads well and describes key concepts clearly. Just some friendly suggestions for the authors to consider -

- IMHO introduction section should be expanded as it can provide helpful clues to new-bees, our published document is not just for the insiders.
[KT] RFC8402 provides the more broader and generalized introduction for SR Policy while this document is quite focussed on the details of the implementation and steering concepts. I will add some text in the introduction to point the reader to RFC8402 for the broader overview.

- Section 2.1, is there any guidance for the IP address for the headend and endpoint?
[KT] Nothing specific – especially so it is not construed as being normative. Generally, the IP address associated with the endpoint node (e.g. Router ID) may be the most appropriate for use or in other cases, the IP address that is set as the BGP next-hop for Service Routes may be used. So it is very use-case specific.

If a node is identified by multiple addresses, from the point of view of the SR policy they would be considered as different nodes, correct?
[KT] This relates to the computation of SR Policy which is outside the scope of this document. There was some text around computation aspects in an earlier version of the draft that has been moved into draft-filsfils-spring-sr-policy-considerations around the WG adoption time. To answer your question, the endpoint address can be mapped to a node which becomes the tail-end and then path is computed to that node. In that case, multiple addresses may all map to a single node. This would be an implementation aspect.

- Section 2.1, I am worried that the use of the noun "intent" to describe 'color'. It does not align with the other use of the term in industry/NMRG. I see 'SLA associated with color' in other places. There was a jabber discussion in 110, maybe I am in rough here but wanted to reconfirm!
[KT] In this context, intent is the objective and that objective may be for carrying traffic to meet a specific SLA. This is conveyed by color. I will try to clarify this further in the text.

- Section 2.3, Reference to RFC 8664 for PCEP is wrong here, as <color, endpoint> is signalled via draft-ietf-pce-segment-routing-policy-cp instead.
[KT] RFC8664 does specify in its intro that it is for signaling of SR Policy CP. However, the ability signal multiple CPs and signaling of color was introduced by the draft-ietf-pce-segment-routing-policy-cp. So perhaps we should use both references? I will update for the PCEP draft reference where appropriate.

- Section 2.3, What are the 8-bit values for the Protocol-Origin, is there an existing registry that is used here? Is it - https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4 , should it be listed in this document perhaps?
[KT] These are not code points but suggested default values for the Priority assigned to each protocol. An implementation may use a completely different scheme and/or make theme configurable. I see that https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2 does not clearly indicate this and perhaps the authors should clarify that the Protocol Origin in that PCEP TLV is used to tweak/signal the Priority value to be used for that particular CP in the tiebreaker.

- Section 2.4, For ASN, maybe add "If 2-byte ASNs are in use, the low-order 16 bits MUST be used, and the high-order bits MUST be set to zero.". For IPv4 Node Address, I would suggest adding the high-order bits MUST be set to zero!
[KT] Ack – will update that.

- Section 2.5, in draft-ietf-pce-segment-routing-policy-cp, no further clarification is given about the Discriminator and it simply points to this I-D. This draft says it is left for the future for PCEP. Since the I-D says tuple <Protocol-Origin, originator, discriminator> uniquely identifies a candidate path; we need to specify clearly how to populate the discriminator value in PCEP in this I-D or in PCE WG I-D (it cant be left for the future IMHO)!
[KT] I can see that https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2 does allow for signaling the Discriminator value as part of PCEP TLV. I will put an informative reference to that document instead of “future”.

- Section 2.7, we need to say that preference is a 32-bit value (as done for other fields).
[KT] Ack

- Section 2.11, why only a SHOULD and not MUST in "Only the active candidate path SHOULD be used for forwarding traffic that is being steered onto that policy."?
[KT] It is a SHOULD to allow for a non-active or second best CP to be used in FRR scenarios – Sec 9.3 and there may be other reasons for implementations/use-cases to trigger similar behaviors.

- Section 3, The focus is on SR headend, some text on SR-DB at the controller would be nice. Further, in "A non-attached (remote) domain topology MAY be learned via BGP-LS or NETCONF."; could we clarify that this is at the controller?
[KT] Actually it should be SR Policy computation node – so it covers both headend and controller. Will clarify.

The PCEP references should be changed to draft-ietf-pce-segment-routing-policy-cp.
[KT] Ack

- Section 4, there should be rules regarding which combinations of segment types are allowed to form a valid segment list. Cant mix SR-MPLS and SRv6 for example!
[KT] Ack

- Section 10, It might be a good idea to acknowledge security considerations from the SR policy architecture point of view: how various SR policy parameters and attributes could be exploited to make a headend to forward the traffic incorrectly. It is better to add details that clearly show that the authors/WG have given it a thought and analyzed the implications.
[KT] As a reminder the SR Policy has been introduced in RFC8402 which covers these aspects of incorrect routing and other challenges associated with source routing. This document is only providing the details of the implementation construct/framework for the SR Policy.

- Section 11, What is the range of the value for Segment Types? A-Z only? It would be good to be clear about this. With A-K already allocated, worth thinking if this is too restrictive and not future-proof. Perhaps we could think of the value as a string that is currently populated with a single alphabetic character.
[KT] String can become freeform. How about A-Z, then AA-AZ … ZA-ZZ – that should be a large enough space?

- Since the I-D talks about policy configuration, explicit candidate paths, verification, SR-DB, etc. I don't want to add work for the authors but I do feel in this case a dedicated manageability consideration section would be useful :)
[KT] Good catch. I will add it. It is not much work really since we need to point to RFC8402 which introduced the SR Policy and an informative reference to draft-ietf-spring-sr-policy-yang that the WG is already working on.


Nits
- Expand on first use: SRv6, SRGB, SRLB,SRLG, SRH, BSID, PW, BFD,
- s/SR DB/SR-DB/g
- Section 2.2, s/via protocols like/via protocol extensions like/
[KT] ack

Hope the authors and WG find these suggestions useful.
[KT] Yes, definitely.

Thanks,
Ketan

Thanks!
Dhruv
On Fri, Apr 16, 2021 at 12:27 AM James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>> wrote:
Dear WG:

This email starts a 2 week Working Group Last Call for draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring