Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-sr-policy-safi-00

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Tue, 30 April 2024 15:59 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B54C14F6B2; Tue, 30 Apr 2024 08:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.662
X-Spam-Level:
X-Spam-Status: No, score=-7.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.669, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b="q2YJdcsA"; dkim=pass (1024-bit key) header.d=juniper.net header.b="Ouniv19/"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrV-vDQLSKJv; Tue, 30 Apr 2024 08:59:17 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE9AC14F691; Tue, 30 Apr 2024 08:59:17 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 43U8Nb4f025553; Tue, 30 Apr 2024 08:59:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; s=PPS1017; bh=rTRzp7CBFJlXQcfnxfbNyO 6V/CO2v13hLPBrxLArvCY=; b=q2YJdcsA4wMYwUuO2N4+1rtTRMt/sBG3pBE/kM sF/DgR/M0zP1oweJSu4IRrBLgfES2YIhkCmwIhCAU6rCXgd+Ahsc+kt4YyJzFDZu fVQJPZVSDiYsTYC58VKK0UHybiGwOzAUemRqGF6M8dm6uKctAC7sbq5BfilBdINY MtI9kb2PmlkhqVgAurQrgo18uj/5XangpHmBwxP82ObsUrqioJPuRHg7ULo9w1z8 CkXvGvdghghYqbrkZGvrkbuRpe3/yFE18xW7D40djF5x82JZcUel26C1DOuRCcVF HxNH5NDt0qyGahv+rW+fpl0KvzikcwqOoUbtJM28iFshVOpQ==
Received: from sa9pr02cu001.outbound.protection.outlook.com (mail-southcentralusazlp17011008.outbound.protection.outlook.com [40.93.14.8]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3xrym681fd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Apr 2024 08:59:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LEirz3TsSBIqBexk3jeaCvOrzVSTAvIUx/OWjFmnKYEgji66OYV1Os6gmDsfFnL4TAQEm6TKtz84AQNAhVMqwACkDA0trJjOYX7ER03/SvhoSuMAtr01ztua1yyTqe+UXUIAhPBGvz2shX8CpWKh7+Sac3kNTTXakszso1WlV3orYh5Z+cQjj8IQL1Ww54Imt+0rbW7mGa7R3HUjMnw4cBMo2UGSRl3GrhDSMTV2BO32N++Wi59Zd16ndIdetU0GTJ1qq8hW2gqit5tAz1Dczhs7MvdFgscG+9ZMWyroqEP5sqpSumSWkohsXJuxTDyD4KV1uLAwxbk5M+8zR/iKuw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rTRzp7CBFJlXQcfnxfbNyO6V/CO2v13hLPBrxLArvCY=; b=mmYd6OwID7agw25R03s+6GOnXijL+owXnI+03uT6G7lUb8+HLMwL1TJG1ZT+TXM/oiHOQUFa2/tq2vDXHua2pepycM7PX0oiLeXL/aXfy/MGvPdKDoK2YtpFpbR4wvFqO/7NUT1ZoVcfNTzU/efv/MCr5wgMEFNetujUjcihYd/1Wk5DV8IOyoM/hiS8ZbXeTyTrFtE/AUJj4iFiW3e9XMDmaQqaR8R4iZiKprAnRGbd/QWoZYhgJ0NmG/OwsI5ZTpNszV4RlRrEpe/gD3E+kTbbzjSvRHsYag3kx4vjDcK2La/lMpk2C+/eIDCQ4Wq9+5C+x6g6GjWlldgfP+2OsA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rTRzp7CBFJlXQcfnxfbNyO6V/CO2v13hLPBrxLArvCY=; b=Ouniv19/gGMyGzeEka/kgeXhRyUVdyVvwogeCpkSmzOXrbCznHpgMpVL3vUo7EzZTqexsv22vAPCynsQSfh+Xav6H+PQIbg7M/L5ZhuYRwvL1MkVa6KcaIwDnaEs2RN28/6wXqxgSq/tiJayMSAA+P2X/Ar52KYVM+shX6W1Zb4=
Received: from IA1PR05MB9550.namprd05.prod.outlook.com (2603:10b6:208:426::16) by PH7PR05MB9309.namprd05.prod.outlook.com (2603:10b6:510:1b0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.42; Tue, 30 Apr 2024 15:59:11 +0000
Received: from IA1PR05MB9550.namprd05.prod.outlook.com ([fe80::8a79:8839:570e:a429]) by IA1PR05MB9550.namprd05.prod.outlook.com ([fe80::8a79:8839:570e:a429%5]) with mapi id 15.20.7544.019; Tue, 30 Apr 2024 15:59:11 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-sr-policy-safi.all@ietf.org" <draft-ietf-idr-sr-policy-safi.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Thread-Topic: Rtgdir early review of draft-ietf-idr-sr-policy-safi-00
Thread-Index: AQHaa+K6OpEx98Tp70Cy9ei3edECH7EjA1eAgATBGoCAEs1oAIBBoN0AgAT65vA=
Date: Tue, 30 Apr 2024 15:59:11 +0000
Message-ID: <IA1PR05MB9550A81FCAE8B3292803ABB9D41A2@IA1PR05MB9550.namprd05.prod.outlook.com>
References: <170926285323.21559.2544259526462856240@ietfa.amsl.com> <CAH6gdPztdv-pXF1KyfJyYuWHX4ivpXG5UDDr1+H+oC3vBgmB+Q@mail.gmail.com> <IA1PR05MB9550EE86ABE42D271774A620D4232@IA1PR05MB9550.namprd05.prod.outlook.com> <CAH6gdPxeVMPSk=S9UOmo0bcqDNKUXo1jR8yNOFVyHJXTrW60FA@mail.gmail.com> <CAH6gdPxtMnz5C5tqU92UaUuCFSib0cyt1A7Hmb+vMQCzJHFLvQ@mail.gmail.com> <CAH6gdPw+ZtfNio2aPj7MBEP-LNW=K=rOyqL1f70G+i3DOxLP1w@mail.gmail.com>
In-Reply-To: <CAH6gdPw+ZtfNio2aPj7MBEP-LNW=K=rOyqL1f70G+i3DOxLP1w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=55fbc272-d6e5-467b-b422-e62113d5ef9d; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2024-04-30T13:31:22Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR05MB9550:EE_|PH7PR05MB9309:EE_
x-ms-office365-filtering-correlation-id: b5ed944c-103a-4a68-a1e6-08dc692e79fc
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GntwEQwYCmAf8jZGVf4/Pu+dfnuvA+ETKQsivhUbeBtU8o2m4Ymdn1lGnST5n1Yj+aMigc3uUnG6N7Ob2SU0b4oLPvQ0h6l7yz2S2i0jDULof75og/beiA8sgzY0jhmnE//HUj5RbaIPaYArnYXN/9keFyS/bkGXbhq1IC4hf6A0J6HZLNzYuxl2pnliuAKQWjaYfQrCArwRHAH8gfbiGttWpWIsWC9NT/B28NTSwoshcN8kLyPCYCx/Ki3qUMvqcQhwcVu0wkd2/0dOxds0/jkdd+7ajRadm2hqWAr2RSPyiVkslU7yJiuoKsJSz8bT9/lj1irHe+wTVFbZ0U6Xp5upE5H8nP0eb/wbjjnY/NeYZI3bWjg+KM8o9ztA6+Cs1ZDbhwbqCW466vziHs/lLVyY2vOmeqF7ukhM7T7FsMYTB6JzhRU/SNRqwIzpIpl2KttLz9mUUDFhh+FlQ5uGpEJSvyRq6zqCeGZYQsY9XgeU43o8FweXyApxn6D52ZAf9FqN7bJNR9fvod0i6xbVboIzQDvQ/AOlUDhplOK0tmEgha1svTUvkv/+84yJjnYtnmyjeIUi1oggMP6cMzBWf98yM+y/ydLPNvALda+8BVcU/4ACMBycYPOAHELMfP1xm4CSSKmTE3vYyJKcZIYtabNpvLvlVqf2t8EG4LBhtZUIb4+OzHkZ1/D3Ng0VEkF+jfW+M0vUcmpECss4i9kXcW80cWKAF0ske0fkNP/SXeUbfR6OISIzKCOoxIyPUJ8sKYO+VtmgQDOBA0Cw2wTxbSJF155tOVbvz79w2pRMQ6P29XItfVp6oua1v3h8tIM70bFuXC633d6ohDiADCR7/BgIiDC5ZrGqDxo5rpfhqoRUszaqR/w/kRfdLToCjU6CTIw7N4iBIcREbz0OZ1I0iOuNGC0LoZYDMZkik7HgF9H0a7daUCH2CE0+rnWj+Nqq2ORwqounkWBoWcdL5sg5D6HgxjvLOHFeQfU5pQSYBMgGfYwkcGWEwZQEO9SBNnz2XTFZUY4hOK2lOYWBUglBM0iozc+dSqGjlMdINI5JrEGVEAYNcNTwfQu+IzTLpS36YqEBT0coiF2mclTg4no/oI2DwBuwvEoWHqG1t8gP8ayhN29rPFzWq63kNu6aU2ocBBEtC2jMJR58+IksxSRmbmwGfa6QToEEuY5IuReyvp/LDvqKeTzAWLT/GRAx5eSMKo+7OGRx+MU8cGwZXz7i0kJwAIU4Y4Lfxj7I+vVxma3YEmJyEF9tUf5ZjOvCnOfHy4aaKOf92gZLgbfXje5wmw8I7VgHzacSTjLpJjmlwnBgkyezeV+gjzNixrLEUOANlMsncymbo9Narz4DxwZgRQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:IA1PR05MB9550.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(1800799015)(366007)(376005)(38070700009); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: DGjWOm4D26/ycaUOpcdDUn3+IBZN8jC63CZjZ2qQtMAWvCOupriU+pA8GD283vkbJ7llAQgJeC3w/vYrSNKmKk/L2i/L5EWgznn8qItHoqW+XYIaE2i1A0vKLJBaTXSporuz4F/yrybPlsLsqFcmU4nSk3DogyHXS0xrzX6BSDRjM02WCU59iQW5s3ka9Ac16d8WwZ/bDW56jfVPVDHk/+ZQ7r6mUOj0Xa0cHdoJqd6/g79nAbG1dCc041lqEf9mIU87HPR4NmgyNE/f3XIsJ72Q6zIKXcM3m1m2mmXDXYuZ6Te20BR6nlDsOHTqLw5SEX7JkGk/hckZ+3MKDMZ2J9rDRQ7AeY9j071btcZg0WFMJQxekjMk1VbBrckz6J6VMi7C2/vtwRp9IYfquqlMuQPIT/ThbW0tz+dO3BQMsQXtfqO3lEYuZpVEFs+tG9dcgT/YJx4LiA92bZWwkBP0rCFbcEqwY3mo1AREuHTofG2N7uInn1bF7qBjukrg5M7B3F9sfXk5o1MuFlbAljWtKh1qim4ZMIZq1guFoEIwPP/BvvEDgYablfuKp/qCANjmr4J4sU3Hr3uqVU8UhG5RZcZIFlSOkdbI1uCPPV6gDApCCk7+R794TGI624JE7Z7O1y7WDAi22fTnPB+3411TRr8ftuPS+t56Pb8gK5hbfe+X/W9V+qpOWJ4tQs0G8wROD1j4XDDdlQkSIWFTpOhoEs6m/4XHx0EKxQDyniAa7mPZIcJSrJFUc1IJP8QI+23cEFOofLAF7utmKIMd+AWdIaAkAQW2Z38lrgqT+scXHZH8lXIhEZc7d/U658HG+NeAl/AuWPDpXrBtmQjBM+jlmLCpFH1BVEjJ+rLv769gMGirEBGScP5l7O9qVVHIBcXBmFUe7RSi2zP7wgCwZYQyAgn7hdcgy0OLQQSblj0w9XQ9eOtix6Jr4RTCVbzKTg65cNfqt1gFqi/kriFl4SLgP/2IL+3UV8zOwDtsi5aXtmDl5qLlLtbWIad/nAFlzMlbCxJmsMME963soVns58IUw5C2UQKW0LlOPbRkGZgFEhc4EKSMslnznbWKeJJAbLMcXBrVsNUP6CvNGqORlnKv7zDaEgKv6ReX/FYc4R0B+5bripFxMv36rwVJyx/ujjMec4qx08XytZ9OmroBQhBJBgh6r5YLRMqNV1yJJ8oyWXSMIWUkBSyo5KnumYNaJYJW6vA3VdNYJR81ZDJKDR6eU6xwJFTgSRqr2H/L3vO9exDVECB7KDFjfGB6zExMOnYWGQhQ5Stj2TsTmc99GcLWpA+FywJh3DrQvoapFwejUpVCAswRNZg06zBDhd7vKI/uvImFsvdWTzRPktzB1dy2zJB0VkQUUNW7RmBtlyyZ2VV/YK8AiuwM5PfBetn5Pv5QByGmKWdPHXNBfdFsCJzjzxnZoFrzE5CD9Hm5YNeA8fp2hQg4F3AFCfkHwaqv/QdQ/ksJni4FKzrPP3t3JOBbkH4H8aHd1OuWi0q8Ed99fYorGD6a0UAh6Oxe7edXXGZL4grkpGD46hhuyNaToPXVqyudZpPbkJTa8Pu78Zs43KjjlihQkNIU8eWDTYLeOqTd
Content-Type: multipart/alternative; boundary="_000_IA1PR05MB9550A81FCAE8B3292803ABB9D41A2IA1PR05MB9550namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR05MB9550.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b5ed944c-103a-4a68-a1e6-08dc692e79fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2024 15:59:11.5201 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: V/SAsCgaBIGXDULl3P7lIR0vxA4N3q1viO7NfivyZP3+6sPQcAzW8qXx7q/LGkm8gcb3QDYV9Fbdlh7AS29nZQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR05MB9309
X-Proofpoint-ORIG-GUID: A72MO8a_fTQYT7o68vC0mgkKilgADfnY
X-Proofpoint-GUID: A72MO8a_fTQYT7o68vC0mgkKilgADfnY
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.650,FMLib:17.11.176.26 definitions=2024-04-30_09,2024-04-30_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 impostorscore=0 adultscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2404010003 definitions=main-2404300113
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/vIEvs-C0Z_46wPGKW1RD9ejGURE>
Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-sr-policy-safi-00
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2024 15:59:21 -0000

Hi Ketan,

Please see see zzh2> below. Only one point about “deprecating” is important – others are nits.



Juniper Business Use Only

On Sat, Mar 16, 2024 at 8:45 PM Ketan Talaulikar <ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>> wrote:
Hi Jeffrey,

An update has been posted which includes some of the changes that we've discussed on this thread.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-02<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-02__;!!NEt6yMaO-gk!DlUR-MNAN113KrtdcUWpy3xqDeIkpr37AyhMVHGQkv7m3AE7UFo_rGVGp85lOeATMsW-KsOkbi95qfuioez5uA$>

Please let us know if there are any outstanding comments that remain to be addressed.

Thanks,
Ketan


On Mon, Mar 4, 2024 at 9:37 PM Ketan Talaulikar <ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>> wrote:
Hi Jeffrey,

Thanks for your quick response and feedback on this draft. Please check inline below for responses with KT2.


On Mon, Mar 4, 2024 at 8:16 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Hi Ketan,

I was finishing up this email before seeing your email about the posted version. I have not had a chance to go through the changes, but to get my questions to you quicker, let me send this (even though some may have been answered by the updated version).

Please see a few points below. I trimmed the text to focus on those.



   An SR Policy intended only for the receiver will, in most cases, not
   traverse any Route Reflector (RR, [RFC4456]).

Is the above paragraph correct/needed. I suppose in most cases
they will traverse RR after all - whether it is from a controller or
an egress PE.

KT> It is needed. RR is not required and not used in many deployments that I know of. It is a direct peering from controller to router.

Zzh> OK if you say the most BGP deployment is not through RR 😊

How is further propagation prevented after the headend is reached?

KT> This is covered in section 4.2.3

Zzh> I think a little more text is needed (more below).

   *  One or more IPv4 address format route target extended community
      ([RFC4360]) attached to the SR Policy advertisement and that
      indicates the intended headend of such an SR Policy advertisement.

and IPv6? s/format/specific/?

KT> Fixed. Use of IPv6 specific RT is not specified in this document.
Zzh> I see that it’s based on BGP Identifier which is 4-octet only so that’s reasonable.

   It is important to note that any BGP speaker receiving a BGP message
   with an SR Policy NLRI, will process it only if the NLRI is among the

There are a lot of "processing" before it is deemed "among the bet paths",
right? Do you mean the "SRPM" will process it only if the NLRI is among
the best paths?

KT> Yes and Yes.
Zzh> I see that the document intentionally distinguishes between BGP and SRPM. So the above distinction is necessary.
Zzh2> I think it should be changed to the following to be clear:
   It is important to note that when a BGP speaker receives a BGP message
   with an SR Policy NLRI, the SRPM will process it only if the NLRI is among the
   best paths as per the BGP best-path selection algorithm.

Zzh2> You don’t need to post a revision for this one alone, though.
2.3.  Applicability of Tunnel Encapsulation Attribute Sub-TLVs

   The Tunnel Egress Endpoint and Color sub-TLVs, as defined in
   [RFC9012], may also be present in the SR Policy encodings.

Why do we say the above given the following paragraph? They seem to
be contractive.

KT> There is no contradiction. We don't want the attribute to be considered malformed due to the presence of those sub-TLVs.
Zzh> It seems that the above paragraph can be removed – the following paragraph alone is enough.

KT2> Ack - removed for the next update.


   The Tunnel Egress Endpoint and Color Sub-TLVs of the Tunnel
   Encapsulation Attribute are not used for SR Policy encodings and
   therefore their value is irrelevant in the context of the SR Policy
   SAFI NLRI.  If present, the Tunnel Egress Endpoint sub-TLV and the
   Color sub-TLV MUST be ignored by the BGP speaker and MAY be removed
   from the Tunnel Encapsulation Attribute during propagation.



   When the Binding SID sub-TLV is used to signal an SRv6 SID, the
   choice of its SRv6 Endpoint Behavior [RFC8986] to be instantiated is
   left to the headend node.  It is RECOMMENDED that the SRv6 Binding
   SID sub-TLV defined in Section 2.4.3, that enables the specification
   of the SRv6 Endpoint Behavior, be used for signaling of an SRv6
   Binding SID for an SR Policy candidate path.

Is there a choice here? Shouldn't the behavior be that traffic with that
Binding SID is steered into this policy?

KT> What is meant by SRv6 Endpoint behavior is specified in RFC8986 - e.g., End.B6.Encaps, End.B6.Encaps.Red, and others could be defined in the future.

Zzh> Now I see that the first “Binding SID sub-TLV” in the above paragraph is not the “SRv6 Binding SID sub-TLV” but the one that can be used for both MPLS and SRv6 (I missed that). Then the paragraph makes sense.
Zzh> It helps if the paragraph moves down to after “If the length is 18 then the Binding SID contains a 16-octet SRv6 SID” and changes to the following:

KT2> We put it up front so it is more clear - putting it at the end may result in it being missed. This is an editorial thing and I prefer keeping it as is.


… in this case, the
   choice of its SRv6 Endpoint Behavior to be instantiated, e.g., between
End.B6.Encaps, End.B6.Encaps.Red [RFC8986], is
   left to the headend node.  It is RECOMMENDED that the SRv6 Binding
   SID sub-TLV defined in Section 2.4.3, that enables the specification
   of the SRv6 Endpoint Behavior, be used for signaling of an SRv6
   Binding SID for an SR Policy candidate path.



   *  Binding SID: If the length is 2, then no Binding SID is present.
      If the length is 6 then the Binding SID is encoded in 4 octets
      using the format below.  Traffic Class (TC), S, and TTL (Total of
      12 bits) are RESERVED and MUST be set to zero and MUST be ignored.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Label                        | TC  |S|       TTL     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 6: Binding SID Label Encoding

      If the length is 18 then the Binding SID contains a 16-octet SRv6
      SID.



2.4.4.2.2.  Segment Type B

   The Type B Segment Sub-TLV encodes a single SRv6 SID.  The format is
   as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |     Flags     |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                       SRv6 SID (16 octets)                  //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //     SRv6 Endpoint Behavior and SID Structure (optional)     //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Flags: 1 octet of flags as defined in Section 2.4.4.2.3.

   *  SRv6 SID: 16 octets of IPv6 address.

   *  SRv6 Endpoint Behavior and SID Structure: Optional, as defined in
      Section 2.4.4.2.4.

When this is part of a segment list, what is the significance of the Flags and
SRv6 Endpoint Behavior and SID Structure?

KT> Please refer to sections 2.4.4.2.3 and 2.4.4.2.4 - will elaborate on your further comments on those sections.


   The TLV 2 defined for the advertisement of Segment Type B in the
   earlier versions of this document has been deprecated to avoid
   backward compatibility issues.

Why would deprecating them avoid backward compatibility issues?
If there are implementations/deployments based on earlier versions,
deprecating them won't help.
If there are no implementations/deployments based on earlier versions,
there is no backward compatibility issue.

Perhaps just remove "to avoid ..."?

KT> The WG was polled in this matter. While there were no implementations from "known" vendors represented at the IETF, we cannot rule out something being out there.

Zzh> I mean that “deprecating them” would not address the backward compatibility issue after all if there is implementation out there already based on the old version?

KT2> The backward compatibility part was why we didn't change those TLV formats and used new code-points.

Zzh2> Now I realize that you’re talking about the TLV 2 introduced in earlier versions of *this document* - they’re now deprecated/invalid. Should we talk about this at all? Shouldn’t it only talk about the final procedures/encodings when this becomes an RFC?



2.4.4.2.3.  Segment Flags

   The Segment Types sub-TLVs described above may contain the following
   flags in the "Flags" field defined in Section 6.8:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |V|   |B|       |
   +-+-+-+-+-+-+-+-+

   Figure 22: Segment Flags

   where:

      V-Flag: This flag, when set, is used by SRPM for "SID
      verification" as described in Section 5.1 of [RFC9256].

I have trouble understanding the V-Flag. How is the headend supposed to verify
the BSID or any segment in the segment list?

KT> Please refer to section 5.1 of the RFC9256.


2.4.5.  Explicit NULL Label Policy Sub-TLV

   To steer an unlabeled IP packet into an SR policy, it is necessary to
   create a label stack for that packet, and push one or more labels
   onto that stack.

Do you mean SR-mpls policy?
Perhaps remove ", and push one or more labels onto that stack"?
Perhaps changes "Explicit NULL Label Policy" to
"Explicit NULL Label Behavior"? The word "policy" here gets tangled
with "SR Policy".

KT> This is related to SR Policy with the SR-MPLS data plane.
Zzh2> The wording “create a label stack for that packet, and push one or more labels onto that stack” is really strange.
Zzh2> Again, you don’t need to post a revision for this.

When should the BGP update stops being propagated if RT is used?
Never? or should a matching RT be removed by each matching receiver
and then the propagation stops when there is no RT left?

KT> Yes, it can do that using local configuration. See the next paragraph.


   By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove
   route target extended community before propagation.  An
   implementation MAY provide support for configuration to filter and/or
   remove route target extended community before propagation.

Isn't the above applicable to any AFI/SAFI? Why do we need to specify that?

KT> It goes with the previous paragraph - hence required to clarify.
Zzh2> The previous paragraphs are:

   SR Policy NLRIs that have the NO_ADVERTISE community attached to them

   MUST NOT be propagated.



   By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate

   it to any EBGP neighbor.  An implementation MAY provide an explicit

   configuration to override this and enable the propagation of valid SR

   Policy NLRIs to specific EBGP neighbors where the SR domain comprises

   multiple-ASes within a single service provider domain (see Section 7

   for details).



   A BGP node advertises a received SR Policy NLRI to its IBGP neighbors

   according to normal IBGP propagation rules.
Zzh2> I don’t see “It goes with the previous paragraph - hence required to clarify” so my question remains, but it’s not important.
Zzh> I think it SHOULD remove the RT that matches its BGP identifier and stop propagating if there are no more RTs left, w/o relying on configuration.

KT2> I can understand where you are coming from and IIRC this option was discussed at some point of time during the draft's life as a WG document. The decision at that point was to keep it as an explicit policy option and to not create an exception in the base BGP propagation mechanism. The way it works today is that the BGP Identifier matching is done during "import" into SRPM that is specific to the BGP SR Policy SAFI.



5.  Error Handling and Fault Management

   A BGP Speaker MUST perform the following syntactic validation of the
   SR Policy NLRI to determine if it is malformed.  This includes the
   validation of the length of each NLRI and the total length of the
   MP_REACH_NLRI and MP_UNREACH_NLRI attributes.  It also includes the
   validation of the consistency of the NLRI length with the AFI and the
   endpoint address as specified in Section 2.1.

   When the error determined allows for the router to skip the malformed
   NLRI(s) and continue the processing of the rest of the update
   message, then it MUST handle such malformed NLRIs as 'Treat-as-
   withdraw'.  In other cases, where the error in the NLRI encoding
   results in the inability to process the BGP update message (e.g.
   length related encoding errors), then the router SHOULD handle such
   malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides SR
   Policy are being advertised over the same session.  Alternately, the
   router MUST perform 'session reset' when the session is only being
   used for SR Policy or when it 'AFI/SAFI disable' action is not
   possible.

Is the above generic BGP handling?

KT> Yes, per RFC7606 this needs to be defined for new SAFIs.


   The validation of the TLVs/sub-TLVs introduced in this document and
   defined in their respective sub-sections of Section 2.4 MUST be
   performed to determine if they are malformed or invalid.  The
   validation of the Tunnel Encapsulation Attribute itself and the other
   TLVs/sub-TLVs specified in Section 13 of [RFC9012] MUST be done as
   described in that document.  In case of any error detected, either at
   the attribute or its TLV/sub-TLV level, the "treat-as-withdraw"
   strategy MUST be applied.  This is because an SR Policy update
   without a valid Tunnel Encapsulation Attribute (comprising of all
   valid TLVs/sub-TLVs) is not usable.

The above says the validation of those in Section 2.4 may lead to
"treat-as-withdraw" - I assume this is BGP handling. Does that not
conflict with the following paragraph?

KT> No, it does not. There is a line between what validation is done by BGP and what is done by SRPM.
Zzh> My understanding is that “treat-as-withdraw” is BGP handling (BGP tells SRPM the route is withdrawn) – that’s why I thought that there was a conflict.
Zzh> Are you saying that it is ok for BGP not to treat it as withdrawal but for SRPM to treat it as withdrawal (due to the validation in Section 2.4)?

KT2> SRPM does not have the concept of "treat it as withdraw". It does have the concept of "invalid CP or SL" as specified in RFC9256 and that is how it would handle such semantic errors.

Zzh2> Let’s say the SRPM had a valid Candidate Path (CP) earlier. Then an update comes and now the same CP is determined as invalid by the SRPM. What would happen to the earlier valid CP? Should it be invalidated? I was thinking that is like “treat-as-withdrawal”, but I take it that the BGP route still remains. Iin the case of “treat-as-withdrawal” in BGP, the route will be deleted, right?
Zzh2> Thanks.
Zzh2> Jeffrey

Thanks,
Ketan

Zzh> Thanks.
Zzh> Jeffrey


   The validation of the individual fields of the TLVs/sub-TLVs defined
   in Section 2.4 are beyond the scope of BGP as they are handled by the
   SRPM as described in the individual TLV/sub-TLV sub-sections.  A BGP
   implementation MUST NOT perform semantic verification of such fields
   nor consider the SR Policy update to be invalid or not usable based
   on such validation.



Juniper Business Use Only