Re: [spring] draft-ietf-spring-mpls-path-segment

bruno.decraene@orange.com Fri, 22 September 2023 09:41 UTC

Return-Path: <bruno.decraene@orange.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 65C8CC15106B for <spring@ietfa.amsl.com>; Fri, 22 Sep 2023 02:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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=orange.com
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 wMf4ZmZ6guoR for <spring@ietfa.amsl.com>; Fri, 22 Sep 2023 02:41:38 -0700 (PDT)
Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.210.124]) (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 B127AC14CE53 for <spring@ietf.org>; Fri, 22 Sep 2023 02:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1695375698; x=1726911698; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=16TIFA9gfO1qEjyoes4VOdIgYTdJCjpIZhpEKKeLE5U=; b=ZXthHQ29B6lRl1puefYRd4uS7lCmC7X04opt4/1eplKi1W3jn2GBxxpD tPGbOWSTiZ71q74dSPIiP6K0bRFpeKP2+yX3Py/9UtzUPoyv2hevkx8gz kqhUSqv0oguAOAg0L9pSUtIivhyGsRzXX1/p1jDYB+HvU1Ccw5HtMNtfx sMeQ0saF2g93I6NsZQSCbXIH76WHjHaJPNsTz/9vK4zQn495V3B+E0aGu lRgZeqCCPcwVf2IL8VAFpPCC1vw2yCdG4kXhJYfPsnOfk5DRuwzoxOTEh HWTAjc6X8OzQWm2rBifjOe7JH6B7cW48u7bw6a/XqCva/IN7KDk/8BPX1 w==;
Received: from unknown (HELO opfedv3rlp0d.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2023 11:41:36 +0200
Received: from unknown (HELO opzinddimail8.si.fr.intraorange) ([x.x.x.x]) by opfedv3rlp0d.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2023 11:41:36 +0200
Received: from opzinddimail8.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with SMTP id C21F5762E6E for <spring@ietf.org>; Fri, 22 Sep 2023 11:41:35 +0200 (CEST)
Received: from opzinddimail8.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 526B6762E53 for <spring@ietf.org>; Fri, 22 Sep 2023 11:41:11 +0200 (CEST)
Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail8.si.fr.intraorange (Postfix) with ESMTPS for <spring@ietf.org>; Fri, 22 Sep 2023 11:41:11 +0200 (CEST)
Received: from mail-db8eur05lp2109.outbound.protection.outlook.com (HELO EUR05-DB8-obe.outbound.protection.outlook.com) ([104.47.17.109]) by smtp-out365.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2023 11:41:10 +0200
Received: from AS2PR02MB8839.eurprd02.prod.outlook.com (2603:10a6:20b:553::7) by AM7PR02MB6289.eurprd02.prod.outlook.com (2603:10a6:20b:1be::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.20; Fri, 22 Sep 2023 09:41:06 +0000
Received: from AS2PR02MB8839.eurprd02.prod.outlook.com ([fe80::7521:180c:121b:b32b]) by AS2PR02MB8839.eurprd02.prod.outlook.com ([fe80::7521:180c:121b:b32b%4]) with mapi id 15.20.6792.026; Fri, 22 Sep 2023 09:41:05 +0000
From: bruno.decraene@orange.com
X-TM-AS-ERS: 10.218.35.130-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== YnJ1bm8uZGVjcmFlbmVAb3Jhb mdlLmNvbQ==
X-DDEI-TLS-USAGE: Used
Authentication-Results: smtp-out365.orange.com; dkim=none (message not signed) header.i=none; spf=Fail smtp.mailfrom=bruno.decraene@orange.com; spf=Pass smtp.helo=postmaster@EUR05-DB8-obe.outbound.protection.outlook.com
Received-SPF: Fail (smtp-in365b.orange.com: domain of bruno.decraene@orange.com does not designate 104.47.17.109 as permitted sender) identity=mailfrom; client-ip=104.47.17.109; receiver=smtp-in365b.orange.com; envelope-from="bruno.decraene@orange.com"; x-sender="bruno.decraene@orange.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:80.12.66.32/28 ip4:80.12.210.96/28 ip4:80.12.70.34/31 ip4:80.12.70.36 include:spfa.orange.com include:spfb.orange.com include:spfc.orange.com include:spfd.orange.com include:spfe.orange.com include:spff.orange.com include:spf6a.orange.com include:spffed-ip.orange.com include:spffed-mm.orange.com -all"
Received-SPF: Pass (smtp-in365b.orange.com: domain of postmaster@EUR05-DB8-obe.outbound.protection.outlook.com designates 104.47.17.109 as permitted sender) identity=helo; client-ip=104.47.17.109; receiver=smtp-in365b.orange.com; envelope-from="bruno.decraene@orange.com"; x-sender="postmaster@EUR05-DB8-obe.outbound.protection.outlook.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/50 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all"
IronPort-Data: A9a23:j2ClMK4pD3QOev2lK3oLPQxRtM3AchMFZxGqfqrLsTDasY5as4F+v mceCGiEOqyJMGLzctF/Ydu1/RxSscTTzdFlSAVoqSFgEysa+MHIO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuVGuG96yM6jMlkf5KkYMbcICd9WAR4fykojBNnioYRj5Vh6TSDK1vlV eja/YuHYzdJ5xYuajhPs/PZ8ks21BjPkGhwUmIWNKkjUGD2xyF94KI3fcmZM3b+S49IKe+2L 86rIGaRpz6xE78FU7tJo56jGqE4aue60Tum0xK6b5Ofbi1q/UTe5EqZ2M00Mi+7gx3R9zx4J U4kWZaYEW/FNYWU8AgRvoUx/yxWZcV7FLH7zXeXteiL3nPPeErX29Z1F00QLJU3/fRvODQbn RAYAGhlghGrqt+MmO/+ZsM8w8MpIY/sIZ8VvWxmwXfBF/E6TJvfQqLMo9hFwDM3gcMIFvHbD yYbQWM3MFKcPFsWZRFOUMNWcOSA3hETdxVSsk+Touw77mPJxQF33ZDqKtPTddHMTsJQ9qqdj juepDyiU09EXDCZ4T6Dq32lmuCfpzziQowZHbK8pudW2XTGkwT/DzVNDADg+aDj4qKkYPpUb Ug8+jcnsqUzskesS7HVVB21pnGbsx8FWtNWHMUx6ACLw6/T6QedCy4PSTspQMwnrMIwSiwr3 1ihn87gGjFu9raSTBq17a+OrDW9ESkYMWFEYjULJSMH6tzuu8c1yB3ST91jGbS5ptPoBSzqz i+HrW41gLB7pdUX2rqy50yBiSi9r57VZgEw7wTTGGmi62tEiJWNYoWp7R3X56ZNMZzBE12Z5 iFcyo6Z8fwECoyLmGqVWuIREbq15vGDdjrBnVpoGJpn/DOok5K+QWxOyDVaPFZXO801QifKe 1TfnxJJy5hBJEL/OMebfLmNI8gtyKHhE/HsWfbVcsdCb/BNSeOXwM19TRPLhDuywCDAhYl6Z 83GIJ7E4WMyU/wP8dagewsK+Z4GrszU7U/OT5T6yXxLOpKyPCT9pVstFFaPaPsl4bnsnek42 9NWNs/Pxx8PXfDkOnTT6dRKdQFMKmUnD5frrcARbvSEPgdtBGAmDbnW3K8lfItm2a9Sk48kH 01RuGcImDITZlWedm1mj0yPjpuxAP6TSlplYUQR0a6AgSRLXGpWxP53m2ELVbcm7vd/6vV/U uMIfc6NatwWFGWaoG5ENcKs/dYyHPhOue5oF3v8CNTYV884LzElBve+IWMDCQFSUXLp7Zdi/ NVMKCuBEMpbH1kK4DnqhAKHlArq5iBEwoqermPNI9JJf17r/pQiIj7slPJfHi3/AUSr+9du7 C7PWU1wjbCV/ecdqYCV7Yja9dvBO7UlRSJyQTKEhYtawAGBogJPN6cbDb7UFd0cPUuokJifi RJ9lq6maKNbxgca6+KR0d9DlMoD2jcmnJcCpiwMIZkBRw3D5m9ISpVH4SVOikGJ7pJkg1PrH 26lqpxdM7jPP975GlkMIgZjdv6EyfwfhjjV67IyPVn+4yh0urGAVC2++jGS3TdFIuId3JwNm I8cVAw+s2RTSSbG9v6BlClS+GnKJXsFO0nino9PG5fl02LH1XkeCaHh5vfK3ayy
IronPort-HdrOrdr: A9a23:OpCLmaDtwH7aIXPlHegnsceALOsnbusQ8zAXPh9KJCC9I/bzqy nxpp8mPEfP+U4ssHFJo7C90dq7MAjhHP9OkMEs1NiZLW3bUQeTQr2KqLGSugEIeBeOvdK1t5 0QFJSWYeeYZTQUsS+52njfLz9K+qjlzEncv5a6854bd3AJV0gP1WZEIzfeNnczaBhNBJI/Gp bZzNFAvSCcdXMeadn+LmUZXsDYzue72a7OUFojPVoK+QOOhTSn5PrRCB6DxCoTVDtJ3PML7X XFqQrk/a+u2svLhiM0llWjoKi+quGRi+erN/b8yvT97Q+cyTpAUb4RFYFqegpF4t1Hpmxa1e Uk6C1QRfibo0mhA11d5yGdkTUImQxelEMLxTKj8AfeiN28SzQgB8Vbg4VFNhPf9ko7pdl5lL lGxmSDqvNsfGT9dQnGlq31vitR5z6JiGtnlfRWg21UUIMYZrMUpYsD/FlNGJNFGC7h8ogoHO RnEcmZvZ9tABqnRmGcunMqzM2nX3w1EBvDSk8eutaN2zwTmHxi1UMXyMEWg39F/pMgTJtP4f jCL81T5cdzZ95Tabg4CPYKQMOxBGCISRXQMHiKKVCiD60DM2Klke+E3Fz03pDYRHUl9upDpH 2aaiIniYcbQTOeNfGz
X-Talos-CUID: 9a23:gDD9nm44ESsNqqoq1tss8GoMC/4seUzm1FTLOEOeGH5GT6+NcArF
X-Talos-MUID: 9a23:Wc0T1A3h6coo0HkcbYd7wQDiKzUj56L3B0kRnsU8pNCeOyd5NDPNlQjua9py
X-IronPort-AV: E=Sophos; i="6.03,167,1694728800"; d="scan'208,217"; a="10303966"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VEWD7Wl7+U9kHm9YJK5jWxvsAkD3yhveAPc3Izqc4xjLrGhGQj1LYRWzDKdILhH15u9CojBKLaNnH6t6SYcrkbrPAQzoXmfK7nd7h3S1pxsuyjmrd05MCE69IXwVT8pf0grGHannG4rkzRX82bweCK/T8ssUHboYviocjZbasRN34bWiYiuK59mI4Kb4fzWwvgqhBT7Tedk8IsLQDEvk9N0IDPE3SNlpkHd9zkUeYpfHPZmp6d2F5yjzsTCUmKwcVqvMnHio6YnOdi+H7nl+ZBg0hgk3fVdNAcMGh3A5f2AsAfn81sq+EJHbe4ZDq6lCzkrKHoyZT7eT9XXtDL0JsA==
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=jsb4T56RhIexVKLFvQTsrUGl8UosEoLo0cxhzKtlzeA=; b=CVutyD/eplpLokfSa/fq7HWx/l7mS9vYuxX0q5AOig4/37twrBhYubLP/PIXbrFCK1GJQmKl0qAf3kfCkFbEcnlXvR1QT9anHQRkXJE6zpN/w4m0+cGJPSaPJiQT3dZUoE2Xpt3ot5wCFdhPsrzfUFwQfq5Lu5mq4QzE3UiBx7jjZ+947A0BOW2IYAp2zhHXV++BdVJAGQc8aQoijOQQKrEt9fkgK7a9RZFRLYXMg3NKoghRiW/x9ZUz1aZJN9cjROJMAVKQ/6KBrlOgJbE6rkgLrvDzJc3OiFcmatEb1XiHFiQZwVYtIznmlBX0znH26Aw4OC74mze5yQrHO8xiQw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=orange.com; dmarc=pass action=none header.from=orange.com; dkim=pass header.d=orange.com; arc=none
To: Cheng Li <c.l@huawei.com>
CC: Weiqiang Cheng <chengweiqiang@chinamobile.com>, Xipengxiao <xipengxiao@huawei.com>, "spring@ietf.org" <spring@ietf.org>, James Guichard <james.n.guichard@futurewei.com>, Stewart Bryant <stewart.bryant@gmail.com>
Thread-Topic: draft-ietf-spring-mpls-path-segment
Thread-Index: Adm0yKBf68bXFQtZRNikkDrURktqwABN6NzQA878T9AAAfZBMAArGUbwBrk7qMAALwNgAAEvS5PgAAShMHAAIWAJ0AFsVjkwACgvxvA=
Date: Fri, 22 Sep 2023 09:41:05 +0000
Message-ID: <AS2PR02MB8839219C1E2F048F7AF3170FF0FFA@AS2PR02MB8839.eurprd02.prod.outlook.com>
References: <AS2PR02MB8839A0F038AE3B20067A4184F036A@AS2PR02MB8839.eurprd02.prod.outlook.com> <d47bbd1b7a984fdf9ae6094cd1b2f78d@huawei.com> <AS2PR02MB883956C9FCEC2E1B7080EC7BF00BA@AS2PR02MB8839.eurprd02.prod.outlook.com> <AS2PR02MB883945E5152DC506EB768532F00BA@AS2PR02MB8839.eurprd02.prod.outlook.com> <98f34801b0954e4bb3ccc6ef5c7fd167@huawei.com> <AS2PR02MB88398A956EC86582A7C6F6B7F0EFA@AS2PR02MB8839.eurprd02.prod.outlook.com> <4e60f6fd39f54da4b8607ab34daaf7dd@huawei.com> <AS2PR02MB8839BCFAED5F6BEFF9D3F60AF0F0A@AS2PR02MB8839.eurprd02.prod.outlook.com> <4a0cf0981c814140a781d2a3817b3c61@huawei.com> <AS2PR02MB88390E893A0A5E8BB6A5F694F0F7A@AS2PR02MB8839.eurprd02.prod.outlook.com> <5e090524a4a14f3e8184cb9e28a9671d@huawei.com>
In-Reply-To: <5e090524a4a14f3e8184cb9e28a9671d@huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2023-09-22T09:41:04Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ActionId=0c17103f-cc26-4bc2-880f-e5dd1cfa097d; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR02MB8839:EE_|AM7PR02MB6289:EE_
x-ms-office365-filtering-correlation-id: 1ea3ef4d-c22f-4bc2-09bd-08dbbb500af8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TycImGaK/Ove7z63fpyHdYxpfs6w3cI4+2EizLhSsqeJ0sr94ASBXGr60FHloocm5H4XB3ic/4BnDJEAlrtYINqY/OvPcnDCAKITSB9Z7MTmE++tZPCZqx4+JZd6GpmEglogi42cNAwjOGMh2RUNsIAVMI+/EaYkw3/bFhZXMjjLuOzbyCQAoADpqVW4+9Fl3fW5DEGP1GSuu28tN1gCfOjt8CkxvuFe+ZYAoRACZRPWvoliV6MsSTXhL79KSu9nN7FTidjHHCxVsEeHLPw4u1QRZ5YE+HMbp9bAyKW1OfSF4CH9mrcz0HC/1IygUoPo1vGsY79EPYBIRVKaJz2NbRJ9Pp4f6Z5uFsiNNZKKMjDHImFQORigND47whARlpzwTw3h+p6eR0G6ApCSeQ+Hj54OuuV0VlojpekvGCjkGgJ5iaIc7ZkliyumrLoPhVXHBfyTkqVnnhF1hwwagTG1/m5VerKYeiETF/KJZNdm7tEpQjtRqONXOxJySxRf/hDP9f622pWH2FOcjZqkL0W+nGAU5mxtTwNZIZC2ImKqPb5A4NE8h8blNiR1ZkIJGi3v0TOjpoNi7yGPGJRTvqaHuBUt8rINUpTz8b5Yd93pbOA=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS2PR02MB8839.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(346002)(366004)(136003)(376002)(39860400002)(396003)(451199024)(186009)(1800799009)(41300700001)(2906002)(30864003)(54906003)(316002)(76116006)(6916009)(66556008)(66946007)(66476007)(64756008)(66446008)(4326008)(5660300002)(52536014)(8676002)(8936002)(55016003)(478600001)(71200400001)(86362001)(83380400001)(26005)(166002)(966005)(122000001)(6506007)(38100700002)(38070700005)(9686003)(33656002)(53546011)(7696005)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: zKTKWrLni6rfP3DecQ0YSZGK9UltADtZbi5fCrD4b97OBhx8mg2UxNEVTUA2JCgN2lMBu93RxruRJ/+en+IxzhA2P2gTd1k7VEcI7qXfhGk/Emo8WYCqiIIfVBEzsoBR5lnZ9BtNt5a+NLhkyRDzUOzadovlSlpRYt+yDCFf3IFWkiqYKkyzqE2SgXFmiBfvYZX4sbyzlYhIIBOyLrT4B3hulZs0srsa+qKkfQUY6vFnRfQ+gB/GSqNG9kUn6LPuCAbsfhlSc7TYqYvcTMCR2f1AC8Ta8eeYL6rYp0Onp0G+8siKEAvJlC2yPrNZV6tro40Up9BMSWlyS2EgMil1in769yPK3dpDo6GLi4n9GG9CVMFPT97w553haFWe/mSy4AmNgiF/EHhJ9yEdDOGL20OQK3WN+x/CQwnWawGkeo7+MEJrbLSpOEZU1qvDrcHs/Q3wJexfvAODeJJEywtTA/0w5YFQ+bB7hygpFmUezdJvpQbDDiUT4CNPSmldoceMCU9h5TiHv8fNGwP1+tBg3Mk2nAAtF3Fklcka90BXw28FKRZ57di5Z8thwS8jaIvPiFbV+3/viXCSpXHptl6UmyXijl3kxqdbt3yJNHJz9kATlB5BQP0wykc5jU5mtpH///FR/9YRyMi7wByIa/S+pz+87QedQRc0FGpY/0u2MK9OpQivsGxZDBf8mHurpqIL701XuTC2s6D+OrUK5lo4UctMM2Ec+TLl3kJ2/KCt6J3OxXgBtBcT7RAYTt9JZcLXI77HfnRUV1DSOd9BFkZJUmjE93w8r7ilTIicxl0Kl/BBXZwGrK29YHh85bk8WPemYwwznzrusgj3DWPW5xvb49Ox5lvE1y37hIXY7zbgQ0v+AOLGMnuUApM1jJMqGDZTtzDxtk2TJrKGYQqpqS5NfPWgwBUec9Cv+banGDCf5EPHSQWDwcokfcKrTysQhP+3NZf0pXxndfkohTL4kWeBt0b+Or1l5KlbI3k4NgK+jKaWm7K5hyEKywIxEomOlMXeg1BENMI39LNV8QX429CksgU3MgJA2B/ePL0pJlHhHByE7y3L+hQZHxHlrH4T/qR5qYV412Tn3Se1M0s4c6D81GSlFnIu/mGQtg6JZjtPPgnjZeLGHbkXIvtA4aAwH34X8YkFlKA7hY/9gETJFBPevCLxyxXP/NuPB0dU63dcrIqJhsXtZvT12VrP/Azqf1lr6IkPb85BU/R8Mv4bN2XTGQ1M/o5RkWwqFMaZ9StR+YzoGtLASOTGz0H5mub/SsuNne8ir37DzrLoYp0DYLKRP4ZnVgm3VErylMixO0Ve4xVFek0fQHU81Rsn1BNoHRpUepza4QnQt+XfwoTyCWvBmCEOdrPFtfKjG7mWyPAb772hYBUQuLNTeMrDsZ/X4mMUZZK37fpyibKR5f4wBzOAw5f8r+TK4dd1tVB0WKYGCqeA7fDyjeU8jWrt8H6WlGx/6OJAQiVNLdnZ4ToL6JjvSqGhMYLDRzNR6NyOfaUgzT7Mw8TUIwysPhE81aSZj0U9mmqDpIKdETMyP2Fa6gykhahUe4EG6iJuXL7XNsyb5k1c5RXWEGcJGCqSLyW/Dhgn
Content-Type: multipart/alternative; boundary="_000_AS2PR02MB8839219C1E2F048F7AF3170FF0FFAAS2PR02MB8839eurp_"
MIME-Version: 1.0
X-OriginatorOrg: orange.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS2PR02MB8839.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ea3ef4d-c22f-4bc2-09bd-08dbbb500af8
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2023 09:41:05.8837 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 47D6ByAmC1rPmghhrhMiqJ0XoZcYPvJNcLD74iISj0Xh6Uww5aL1rYbifUEx4MAI3EOMkSAuLWv32T8AZAUBbiYGNMT4PdNOHggPwTTYX2U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR02MB6289
X-TM-AS-ERS: 10.218.35.130-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== YnJ1bm8uZGVjcmFlbmVAb3Jhb mdlLmNvbQ==
X-TMASE-Version: DDEI-5.1-9.0.1002-27890.006
X-TMASE-Result: 10--28.672500-10.000000
X-TMASE-MatchedRID: 1uttSxkBlaXuYusHgJkgygv/9UzFeXITtwi3bXRtaAjpIBL6aTHUUaza 0VmP31K+253vDgNe3q5p71qAvI563odlc1JaOB1T82SgwNf6SK6+y4Y487IcARbglLw9bks20ei xX2oSmF5hWgNOVfhPTGR5WlY/ZLL5b/oIJuUAIuEXCB5ciYU4zkz5vzLEGq8DkHs1AzjpA+yh9b Mmqe83MR6m7J43eS8yfcvgftu2t08p1j2WdPxkF3iywgNDw+2oty9mj1urE9Ic7bE2R176OSSCv akjSesKUNHYJMizeW4kTzJZAOv6JJVRzPxemJL0aXmdXF2Ym8eF7G1bHV1SIUtssRkSqfpNmnpV u2q8UzTt/ps0RmaJf8+0iX9BL4J12h1P6TA0pBtlH44U2Ru12tkY+KIbxMxzcrjETpDjQDdYYdP 5O39EZqcvaj5s3izWLkXZg1jsHsrEkg1PRKiOVJQ7eT0DII9NYUdWP7oX6siHMkwIgRWeC/kkmq kekvE0Zt7LpQmvLXtwrk76NCZH/CrLqyE6Ur/jdmWMDQajOiIsAd51dEn+6P5DR3JiRM229fiLW lzqHPG+tz/CddrFFy+3xqQ44pFWNxqr5qtGGJRMkOX0UoduuUukIs3g1HjeoT+7K9IgTZf4EXi5 HZwxNmXFv4tjudw4HELy2nEQIHD4KPASpfWnuVTclWxRYomgaOWLD7G8i13QCalGjynfE8gYD8K nT7p2U3ljwEApOTCLolIX3+HnzAihQ5NZCXsSsVwPMKjZm1ZqC6S2xst6VOPhs17991vRU3lHOp JPrThO4WXfk8lYP4/ic5fkE2hmF3wQ0cu1bTPqtOCMCMzOYZsoi2XrUn/JJ51KgEwAGdm6rRx26 7m9tpWD5DDAqPadgWyBTm39yBmDGx/OQ1GV8tJHoSpWytSp2qmCd95vcRR6mbStZofcctbu4Wm+ Rqop/nnwJ52QYi+pygCGKFPC+BeYl5uS2QAg
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
X-TMASE-INERTIA: 0-0;;;;
X-TMASE-XGENCLOUD: b1f77b69-9001-462f-869e-a322f20040a4-0-0-200-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/fmBcvjVyYIe2UcohI55qRXQ9mtE>
Subject: Re: [spring] draft-ietf-spring-mpls-path-segment
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 22 Sep 2023 09:41:43 -0000

Hi Cheng,

Latest version looks good to me. Thanks.
Let’s wait till end of next week for Stewart’s feedback. Otherwise ball is in Jim’s court.

Thanks
--Bruno



Orange Restricted
From: Cheng Li <c.l@huawei.com>
Sent: Thursday, September 21, 2023 4:38 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
Cc: Weiqiang Cheng <chengweiqiang@chinamobile.com>; Xipengxiao <xipengxiao@huawei.com>; spring@ietf.org; James Guichard <james.n.guichard@futurewei.com>; Stewart Bryant <stewart.bryant@gmail.com>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Bruno,

Many thanks for your review comments.  According to your comments, we have


l  updated the draft to add all the required info of implementations from 5 vendors.

l  added  info of an interop-test among at least 5 vendors in 2018.

l  Fixed some nits of typo.

Please review the update [1] to see if it is OK for you or not.

In the end, sorry for mis-sending our private thread to the mailing list before getting confirmation from you. I have read several times of RFC1885, and find out it is very useful. Thank you for your help.

Respect,
Cheng

[1]. https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-mpls-path-segment-12&url2=draft-ietf-spring-mpls-path-segment-14&difftype=--html




From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Sent: Thursday, September 14, 2023 12:14 PM
To: Cheng Li <c.l@huawei.com<mailto:c.l@huawei.com>>
Cc: Weiqiang Cheng <chengweiqiang@chinamobile.com<mailto:chengweiqiang@chinamobile.com>>; Xipengxiao <xipengxiao@huawei.com<mailto:xipengxiao@huawei.com>>; spring@ietf.org<mailto:spring@ietf.org>; James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Thank you for uploading the document.

Please find below some comment regarding the Implementation Section,

I would not say that the current section complies with the SPRING WG policy https://wiki.ietf.org/en/group/spring/WG_Policies  in particular for the below points:

-       bullet “1)” in the wiki [1].( i.e. indicate that all MUST & SHOULD are implemented). That should probably be easy with 0 SHOULD and 3 obvious MUST.

-       “We are asking that all items identified in section 2 of RFC 7942<https://datatracker.ietf.org/doc/rfc7942/> be included.”

[1] https://wiki.ietf.org/en/group/spring/WG_Policies


That status of Huawei and ZTE implementations are unclear to me. It’s written “The implementation is under development » and « Maturity Level: Product” which seems somewhat contradictory to me.
Would be good if you could update this section. If it’s a product, indicating the release number would be helpful.
Since there are 3 implementations, if someone rans interop test, that could be useful to indicate but that is not required.

Typo: :s/defination/definition  (*2 : ZTE, Huawei)



My laptop crashed and I may have lost some context and email orders. But probably not to the point of forgetting the email I sent you yesterday afternoon.
For the record, the email thread that you seem to quote below (From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> Sent: Wednesday, September 13, 2023 4:45 PM)

-       has been somewhat edited by you. The one I sent you is enclosed. The main point is that I was not commenting on the latest version of the text.

-       was a private reply to a private thread that you initiated deliberately off-list. Not sure how Netiquette has evolved in two generations. RFC1855 could now be considered old but that is not inline with its  “minimum set of guidelines for Network Etiquette (Netiquette)”

--Bruno



Orange Restricted
From: Cheng Li <c.l@huawei.com<mailto:c.l@huawei.com>>
Sent: Wednesday, September 13, 2023 6:45 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Cc: Weiqiang Cheng <chengweiqiang@chinamobile.com<mailto:chengweiqiang@chinamobile.com>>; Xipengxiao <xipengxiao@huawei.com<mailto:xipengxiao@huawei.com>>; spring@ietf.org<mailto:spring@ietf.org>; James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Bruno,

Many thanks for your confirmation. I have uploaded the draft. However, I also can not find out the non-ascii character. Crazy ☹

Now we may only need to wait for Stewart’s confirmation and then we can move into next step. Ping Stewart 😊

Thanks for your help and patience.
Li Cheng



From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Sent: Wednesday, September 13, 2023 4:45 PM
To: Cheng Li <c.l@huawei.com<mailto:c.l@huawei.com>>
Cc: Weiqiang Cheng <chengweiqiang@chinamobile.com<mailto:chengweiqiang@chinamobile.com>>; Xipengxiao <xipengxiao@huawei.com<mailto:xipengxiao@huawei.com>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Thanks.
Works for me.
I’ve just added, enclosed one sentence to define the Path Segment itself (in addition to the PSID) and saying that this is a local segment:

# Path Segment

A Path Segment is a Local Segment which uniquely identify an SR path on the egress node.

Also IdNits complains about 1 instance of lines with non-ascii characters. Could you please fix it?

Thanks,
--Bruno



From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Sent: Wednesday, September 6, 2023 6:02 PM
To: Cheng Li <c.l@huawei.com<mailto:c.l@huawei.com>>
Cc: James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; draft-ietf-spring-mpls-path-segment@ietf.org<mailto:draft-ietf-spring-mpls-path-segment@ietf.org>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Thanks for your reply.
Please see inline [Bruno2]



Orange Restricted
From: Cheng Li <c.l@huawei.com<mailto:c.l@huawei.com>>
Sent: Thursday, August 3, 2023 3:18 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Cc: James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; draft-ietf-spring-mpls-path-segment@ietf.org<mailto:draft-ietf-spring-mpls-path-segment@ietf.org>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Bruno,

Thanks for your comments. I think we are reaching the consensus soon. Please see inline.

Thanks,
Cheng


From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Sent: Thursday, August 3, 2023 1:02 AM
To: Cheng Li <c.l@huawei.com<mailto:c.l@huawei.com>>
Cc: James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; draft-ietf-spring-mpls-path-segment@ietf.org<mailto:draft-ietf-spring-mpls-path-segment@ietf.org>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Following the publication of -10, please find below some additional comments.

-10 has clarified that the PSID is a local identifier on the egress. (not a global one). I think that this calls for some cleaning in some sentences:

§2 “If the PSID is only used by the egress node to identify an SR path, the SRLB, SRGB or dynamic MPLS label pool can be used.”
I would propose to remove that historic sentence.

[Bruno2] you did not comment on this. Is there any disagreement? Is this doc specifying a use of the PSID on a node different than the egress node? If yes, where? If not, there is no such case/”if”
[Cheng2] Agree, I have deleted related text.

BTW, is there still any reason to allocate a PSID from the SRGB?
If not, I would propose to remove that case..

That would make the “Path Segment” a “Local Segment” as per RFC 8402. I would propose to state this.
e.g.
OLD: A Path Segment Identifier(PSID) is a single label that is assigned from the Segment Routing Local Block (SRLB) [RFC8402<https://www.rfc-editor.org/rfc/rfc8402>] or Segment Routing Global Block (SRGB) [RFC8402<https://www.rfc-editor.org/rfc/rfc8402>] or dynamic MPLS label pool of the egress node of an SR path.
NEW: A Path Segment is a Local Segment [RC8402]. The Path Segment Identifier (PSID)  is a single label assigned as per [8402]

“because of mis-matching if the PSID is allocated from a SRLB.”
PSID is allocated from the SRLB, so there is no such “if”. If would propose to remove the quoted text.
[Cheng] I may not agree here. Because actually, there is no limitation or assumption of which block a PSID will be allocated. As long as the value of it is unique on the egress, then everything is ok. It can be allocated from any block, SRGB, SRLB, any other block you want. Is it correct?

[Bruno2] The PSID is only processed by one node: the egress.
As per RFC8402, this looks like a local segment to me.

Local Segment: […] The instruction associated with the segment is defined at the node level.

Global Segment: […] The instruction associated with the segment is defined at the SR domain level.



Why would you allocate a local segment from the SRGB ? (SR Global Block (SRGB): the set of global segments in the SR domain.)
https://www.rfc-editor.org/rfc/rfc8402#section-2
[Cheng2]Though I may think it is not forbidden. People can allocated a label from any label range(except special range) to a PSID, since it will be read by the egress node only, so no error will occur. But it may be wasteful to allocate a Global label to it. But it might have some advantages in operation I guess. Anyway, limiting PSID to be allocated from SRLB works to me.


Other comments:
§2 “When a PSID is used, the PSID MUST be inserted at the ingress node and MUST immediately follow the last label of the SR path, in other words, inserted after the routing segment (adjacency/node/prefix segment) pointing to the egress node of the SR path.”

-       Actually “MUST” would be violated if multiple PSDI were used. e.g. when nested in used (cf §4) in a single Segment List (not requiring binding SID as §4 described)

-       This sentence is not needed if we say that the Path Segment is a local segment (see above) as this is how Local Segment are used.
[Cheng] I see your point. Yes, it is hard to explain here. The sentence is described under a context that when talking about egress and ingress, it is about the path that starts from the egress and the ingress. Therefore, when talking about a egress of a path associated with the PSID, it is the egress node allocated the PSID. Though, in a case of nesting, the whole label stack may combine with other labels, and make the label not at the final bottom.

We might not need the first part, because no matter where the path Segment is used, as long as it can be inserted correctly, that is fine.

Regarding the second part, the label MUST immediately follow the last label  of THE SR path, I think it is correct. What do you think?

[Bruno2] Not sure what you mean by “THE SR path”.
Looking at section3.4 where path monitoring is done at both sub-path and end-to-end path, the ingress is pushing two PSID (s-PSID and e-PSID). Please look at Figure 2.  One PSID (s-PSID) is not the last label of the stack.

https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment#name-nesting-of-path-segments

+------------+
~A->B SubPath~
+------------+
 |s-PSID(A->B)|
 +------------+
 | BSID(B->C) |
 +------------+
 | BSID(C->D) |
 +------------+
 |e-PSID(A->D)|
 +------------+


So it may become,
“When a PSID is used, it MUST immediately follow the last label of the SR path, in other words, inserted after the routing segment (adjacency/node/prefix segment) pointing to the egress node of the SR path.”

[Bruno2] If the doc says that PSID is a local segment, we don’t need anything new. Let’s see if we agree that the Path Segment is a local segment.
[Cheng2]Yes, fixed.


“3. PSID Allocation and Distribution

There are some ways to assign and distribute the PSID. The PSID can be configured locally or allocated by a centralized controller or by other means, this is out of the scope of this document”

The first sentence does not say much (if anything) and the formulation does not seem precise enough for a STD track document.
Regarding allocation, if we say the Path Segment is a Local Segment (just like a BSID) I don’t think that there is anything new. Hence probably there is nothing to say about this.
Regarding signaling, I think it’s ok to say this this is out of cope of the document.

So proposed NEW

3. PSID and Distribution

Signaling of the PSID between the egress, ingress and possibly a centralized controller is out of the scope of this document.
[Cheng]Reviewing it again, I think the section can be deleted, and your proposed text can be added in to the above section. BTW, I think the nesting of Path Segment can be putted into the section of use case, which can make the logic clearer.
Please see the proposed update.

[Bruno2] “A PSID is allocated by an egress node and distributed to an ingress.” Text is good but I’m not sure I would have specified this as part of the “Security Considerations” section. I would have moved or copied in the spec. (in section 2)
[Cheng2]OK, refine the text.

__NEW__
The distribution of a PSID from an egress nodes to an ingress nodes is performed within an SR trusted domain, and it is out of the scope of this document. The details of the mechanism and related security considerations will be described in other documents.


-----

§5, §6, §7.
My reading is that those 3 sections do not specify behaviors (which would typically be specified in other WGs) but are uses cases that could leverage the Path Segment.
I would propose to move those 3 sections into a new section “Use cases”.
Proposed NEW

§5 Uses cases
This section described uses cases which can leverage the Path Segment.
§5.1 Path Segment for Performance Measurement
[…]
§5.2 Path Segment for Bidirectional SR Path
[…]
§5.3 Path Segment for End-to-end Path Protection
[…]

[Cheng]OK, reorganized.

[Bruno2] OK.

----
“Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks. As per [RFC5586<https://www.rfc-editor.org/rfc/rfc5586>] when GAL is used, it the ACH appears immediately after the bottom of the label stack.”
IMO :s/MAY/may

Also this sentence could be rephrase to use the same style than the Entropy Label case.
e.g. proposed NEW
If Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks, as per [RFC5586<https://www.rfc-editor.org/rfc/rfc5586>] the ACH would appear immediately after the bottom of the label stack and hence does not interfere with the PSID which is placed above.”
[Cheng]how about this?
If a Generic Associated Label (GAL) is used for Operations, Administration and Maintenance (OAM) in MPLS networks, as per [RFC5586<https://www.rfc-editor.org/rfc/rfc5586>] the ACH would appear immediately after the bottom of the label stack and hence does not interfere with the PSID which is placed above.”

[Bruno2] OK.

---
§8
“A Path Segment is used within an SR-MPLS domain [RFC8402<https://www.rfc-editor.org/rfc/rfc8402>] and SHOULD not leak outside the domain,”

“SHOULD not’ is not allowed. It’s either SHOULD NOT or should not.
IMO is in this context it’s “should not”
[Cheng]Fixed


[Bruno2] OK.

Thanks
--Bruno

Thanks,
--Bruno




Orange Restricted
From: DECRAENE Bruno INNOV/NET
Sent: Wednesday, August 2, 2023 2:47 PM
To: Cheng Li <c.l@huawei.com<mailto:c.l@huawei.com>>
Cc: James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; draft-ietf-spring-mpls-path-segment@ietf.org<mailto:draft-ietf-spring-mpls-path-segment@ietf.org>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Thanks for the updated draft.

Please see some follow-up points inline [Bruno].




Orange Restricted
From: Cheng Li <c.l@huawei.com<mailto:c.l@huawei.com>>
Sent: Monday, July 17, 2023 12:43 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>; draft-ietf-spring-mpls-path-segment@ietf.org<mailto:draft-ietf-spring-mpls-path-segment@ietf.org>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Cc: James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Bruno,

Many thanks for your work! I am addressing the comments received from the WG, so it is fine/good to me that address your comments in the same time 😊
Please see my reply inline. The diff is generated by comparing with 09. The proposed update tries to address the comments from you, Ketan and Stewart.

If you like to use Github, the link is here: https://github.com/muzixing/SR-MPLS-Path-Segment/commit/3ace59b1e87859950dfac8a967ee560128843b6b

Respect and thanks,
Cheng


From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Sent: Wednesday, July 12, 2023 10:41 PM
To: draft-ietf-spring-mpls-path-segment@ietf.org<mailto:draft-ietf-spring-mpls-path-segment@ietf.org>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Cc: James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>
Subject: draft-ietf-spring-mpls-path-segment

Hi authors,

Since Jim is now the responsible AD, the shepherd for this document has been changed from Jim to myself.
As a result you/this document benefit/suffer from another review.

Please find below my comments/questions.

On a side note, I have two questions for you (for the shepherd writeup):
Are there existing implementations of the protocol?
Have a significant number of vendors indicated their plan to implement the specification?

[Cheng]Weiqiang has replied to you on these two questions. Path Segment has been implemented by a significant number of vendors for several years, and it has been used in large scale networks.

[Bruno] Thank you.
Actually the SPRING WG has a policy to mandate an implementation section in the document. https://wiki.ietf.org/en/group/spring/WG_Policies
Could you please add one?

---

[…]

-----
§2
"The value of the TTL field in the MPLS label stack entry containing the PSID MUST be set to the same value as the TTL of the last label stack entry for the last segment in the SR path."
"MUST" is a pretty strong statement. What is the reason for this? What is the egress supposed to do if this is not the case?
Interestingly, RFC 6790 has a oppositive position with regards to the Entropy Label: "The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding." while the case seems similar (addition of a label "not used for forwarding")
https://datatracker.ietf.org/doc/html/rfc6790#section-4.2

Is there any rule for the TC field? (if not, please say so; if so, please specify the rule)
[Cheng] because we do not use Path Segment for forwarding, so IMHO, the TTL can be any, like 0, or same as the previous one.  How about the following modifications?
___OLD____
"The value of the TTL field in the MPLS label stack entry containing the PSID MUST be set to the same value as the TTL of the last label stack entry for the last segment in the SR path."

___NEW___
"The value of the TTL field in the MPLS label stack entry containing the PSID can be set to any value including 0, or the same value as the TTL of the last label stack entry for the last segment in the SR path."

[Bruno] I disagree with the setting of the TTL to zero. If PHP is enabled, the PSID will appear top of stack and sending an MPLS packet with a TTL zero in the top of stack is not allowed in MPLS
cf https://datatracker.ietf.org/doc/html/rfc3032#section-2.4.2
(Entropy Label could do that because it never appears top of stack)

Actually, the TTL field in the path segment does not seem much different than the TTL field in a binding or adjacency segment. So may be the whole text on TTL may be removed.

-----
§2

"In some deployments, service labels may be added after the Path Segment label in the MPLS label stack. In this case, the egress node MUST be capable of processing more than one label. The additional processing required, may have an impact on forwarding performance."
I belive that when the PSID is used, there is _always_ an extra processing work on the data plane (the processing of the PSID). So I don't think that this is specific to "some deployments" or "service label".
If so, please rephrase.


[Cheng]Well, to me, the sentence is trying to explain the cases that the egress node needs to support processing of multiple labels. But we do have some use cases that the only label is processed on the egress node is the PSID. For example, we only encode the labels of the LSP and PSID in the label stack while the last forwarding label is a PHP enable label. Therefore, when a packet arrives on the egress node, only one single label(The PSID) will be processed. In this case, multiple labels processing is not required.

In other words, this paragraph is only for info that it explains we may have differences with or without services label. If without services label, then the requirement of processing multiple labels MAY not changed. Indeed, the processing of PSID is new in any cases.

[Bruno] A label below the PSID is not limited to the use of service label. e.g, cf section 4 but also with a single PSID followed by transit labels. So at minimum the first sentence is misleading.
Again, I would rather cover the general case. Some proposed text as replacement.
The addition of the PSID will require the egress to read and process the PSID label in addition to the regular processing (such as a below MPLS label or the MPLS payload). The additional processing required, may have an impact on forwarding performance


---
[…]

 ----
§2
"Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks [RFC5586]. When GAL is used, it MUST be added at the bottom of the label stack after the PSID."

Reading RFC 5586, that seems to be already the rule for GAL.  Hence I don't think that this needs to be defined as a new rule (MUST). Especially as this seems to indicate a variation (before BoS vs after BoS) hence this may add confusion.
I would propose:
OLD: Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks [RFC5586]. When GAL is used, it MUST be added at the bottom of the label stack after the PSID.
NEW: Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks. As per [RFC5586], when GAL is used, it the ACH appears immediately after the bottom of the label stack.
[Cheng] OK, thank you!

[Bruno] Actually I introduced a typo  (:s/it the/the)

---
[…]


 ----
§3
"If an egress cannot support the use of the PSID, it MUST reject the attemption of configuration."

If a egress doest not support PSID, how would it support the above rule?
It would seem easier to put the rule/burden on one pushing the PSID (e.g. the 'centralized controller" although the latter is "out of scope of this document")
[Cheng]You are right. We might delete it directly, because it is obvious as well.

[Bruno] You did remove this sentence. However the sentence was written _twice_ in -09, so as a result, in -10 the sentence is still present so there is still a need to remove it.

---
§ 8. Security Considerations

 "no new security threats are introduced comparing to current SR-MPLS"
In general, such statement may be read by security guys as "we did not really bothered studying the security implications". IMO it's better to put more text to explain _why_ there is no impact on security.
As a matter of fact, I'm not sure to agree with this statement: the one (e.g. an attacket) having the ability to signal a PSID value to an ingress, would have the ability to signal any label including a label value used as a service (VPN) label. This would trigger a VPN breach (injecting packets in the VPN).
This may not be not specific to the PSID, but even an "old" RFC with "old" security considerations is doing an effort well beyond "nothing new". https://datatracker.ietf.org/doc/html/rfc5036#section-5
So please consider enhancing the security consideration.

[Cheng] I have to say sorry here, because I am not an expert of security. How about the following modifications?

___NEW___
A Path Segment in SR-MPLS is a label similar to other labels/Segment, such as a VPN label or a Prefix SID, defined in MPLS and SR-MPLS. The data plane processing of a PSID is a local implementation of an ingress node, or an egress node, which follows the same logic of existing MPLS dataplane.

A Path Segment is used within an SR-MPLS domain {{RFC8402}} and SHOULD not leak outside the domain, therefore no new security threats are introduced comparing to current SR-MPLS. The security consideration of SR-MPLS, such as boundary filtering described in {{Section 8.1 of RFC8402}} applies to this document.

A PSID is allocated by an egress node and distributed to an ingress. The distribution is performed within an SR trusted domain. However, the mechanism of distributing a PSID is out of the scope of this document, and its security consideration will be described in other documents.

[Bruno] I think that you mean :s/SHOULD/should
(there is no special new thing to be done)

Thanks,
Bruno

Thanks,
BR
--Bruno

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.