Re: [mpls] On the use of GAL in MPLS-SFC OAM

Tarek Saad <tsaad@juniper.net> Wed, 10 March 2021 14:12 UTC

Return-Path: <tsaad@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8B3A0AA1; Wed, 10 Mar 2021 06:12:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.356
X-Spam-Level:
X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, 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=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=xjL/C9PV; dkim=pass (1024-bit key) header.d=juniper.net header.b=Ut85sJzH
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 hu3A-cOUGFQg; Wed, 10 Mar 2021 06:12:34 -0800 (PST)
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 B1EB63A0A9E; Wed, 10 Mar 2021 06:12:34 -0800 (PST)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12AE6LAs023622; Wed, 10 Mar 2021 06:12:32 -0800
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=zGLk0u9aMc4e3Tpnea5+eVvx2RXddlvv5Z6k3bzyWO4=; b=xjL/C9PV3JFwzdh8NEBIJo/O4UiSdSQsGuuzKnTS4zjL/cwSXIH5x/YAuI9ipUeuYntj hhzgmlLHhvWMra1tsgqPf6JjgELay8RizBMSCPM4U0AhOC4plXftsGLVnT8+itrpvmPx w6NC5eF3dO4g1PpF7+LHlC2IFZDK/CSRSrltij2UPVuWOrnh56D4myCVzTHwHA/Ob1q6 ctitvkbQhXbwMOWCcPRkGaFvwTY2hlJ327NV52wnEZtr9GznCB2K719IU+8iPLr3smGR ikjr2gt4EKEBCTy3fk8+8H6QeWMw+61evxyH2MexB5hRKJs1VGmWfHb+n95IrFtRxZhU DQ==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) by mx0b-00273201.pphosted.com with ESMTP id 376kr695fe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Mar 2021 06:12:32 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZeXgh4aHOoLvJq4YQcj7q2eYF6PHO2cVJOtN+4EZHYBL2dZxScxbAwSylvbf5p91hn2xNdP6uyw+1JE3XNrVRMXG7muqZ1C+4MAGhPH9KPSS0zGvhULOz71O9lKn9iIanJzD7OrLbXkUAGpCnSySc9nWaIwinNuVRRemXe1efJnd61j7gz0QvFefZLVSHKWcKGfaMAZTLpy1p0ifFahplndGUAqZqrPN4XHMnNiwkiiHObK08wK5HxT1QLA+4+hl/MMp+O7DB5rD8iY8HxK2i9lEUl+tfPDXtlHrQKfSfCtW7IvMHDWgrBTIfS2jGFqNQBai3lHC5fVt8gdi0EhIkQ==
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=zGLk0u9aMc4e3Tpnea5+eVvx2RXddlvv5Z6k3bzyWO4=; b=TrAi810MarO/vk9nT5yWbR+pNhQDmZgyXtSjPEF7GLVUfDBYbTpUtCURqcgDt3qKILdAx5tVsbrNMGx/f1QT4Yzoq0V8Vn56PHyzB8zYOok7rcC1W1+KoDQ9dfzMRlO3aK1YIG9mr82zhIjVicTNtRruAr6sCkFDfpK2zMlIBu4SPJO3VhZvb4afbmI/Fi4YD7sS2T5oddrd5/BnJ4kbuBWHfX1puje6YDrhcqrSw03XPDCO2dygekohvr6TJazWfueu9Znub7ZSr2fBSBbdeTgYhF1d1zau8FHE3r8uRvgwC0qdyMC2REox615ySdYQUYXUglXtZrlLYIZb3pNf3g==
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=zGLk0u9aMc4e3Tpnea5+eVvx2RXddlvv5Z6k3bzyWO4=; b=Ut85sJzHFa49B29HkWmP5AodGGSyaj4CS1S7IiRFMWbYAtQed3QSPz+zOUf73Z3JisJDAQiUbh2Ci0XmPLpL3zlsdokS42lJWL5jYAt9Hs8K0OkoFJd3hmg8l18OhrkGv6cgbIhl6qG0Xii+QVn3jU2JkEcS6+eXigMs/0FLF7s=
Received: from DM6PR05MB4138.namprd05.prod.outlook.com (2603:10b6:5:84::32) by DM6PR05MB3946.namprd05.prod.outlook.com (2603:10b6:5:8b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.13; Wed, 10 Mar 2021 14:11:57 +0000
Received: from DM6PR05MB4138.namprd05.prod.outlook.com ([fe80::95fa:89d6:28b6:ee6]) by DM6PR05MB4138.namprd05.prod.outlook.com ([fe80::95fa:89d6:28b6:ee6%6]) with mapi id 15.20.3933.029; Wed, 10 Mar 2021 14:11:57 +0000
From: Tarek Saad <tsaad@juniper.net>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Greg Mirsky' <gregimirsky@gmail.com>, 'Stewart Bryant' <stewart.bryant@gmail.com>
CC: 'mpls' <mpls@ietf.org>, "draft-lm-mpls-sfc-path-verification@ietf.org" <draft-lm-mpls-sfc-path-verification@ietf.org>, 'MPLS Working Group' <mpls-chairs@ietf.org>
Thread-Topic: [mpls] On the use of GAL in MPLS-SFC OAM
Thread-Index: AQHXFbdUZcfxq6OrDEyQQ6iTAypllw==
Date: Wed, 10 Mar 2021 14:11:57 +0000
Message-ID: <E338C962-6BCC-4916-96FB-DC99FFDE6F14@juniper.net>
References: <CA+RyBmXf_Nzn3GxW+1Q1LFjcQ8zUpR9YEMBGyQJ0ODJPcBtD3g@mail.gmail.com> <3688C3DB-2583-4A8D-A9F6-1AF2D05875D0@gmail.com> <CA+RyBmViEB0A-EG6x31E8wes+ytzaLosu4SNzFusOKDM+op8+Q@mail.gmail.com> <0a4201d715af$5605f4d0$0211de70$@olddog.co.uk>
In-Reply-To: <0a4201d715af$5605f4d0$0211de70$@olddog.co.uk>
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_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=03bb72a0-70a9-4450-99d4-1ea41b41d498; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-03-10T13:58:31Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;
user-agent: Microsoft-MacOutlook/16.46.21021202
authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [2607:fea8:e31f:e400:fcea:6038:e31c:70f7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 213f61fa-9476-4b1e-b717-08d8e3ce7710
x-ms-traffictypediagnostic: DM6PR05MB3946:
x-microsoft-antispam-prvs: <DM6PR05MB3946B8C4A7A1C01A4E6AD4B3B7919@DM6PR05MB3946.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lWfX+PE4kZS+3oYVICqY0IMU0uTe63Xjvfp9fYh28GiDLCp3LctYOMvv+Veo9yRALkCLIquJSimAQquRQ58fxUvxY35mCoDYP2Vp8bo81Jfflbc26vQBF3UKsiEiNAt0rUQ3/X9/c5sppcsAhKO/YHmWVpHqIPCZdvGyTd+GiAjOpI4AC7MntWyw7RsdTBh98Gf4+ceaFMFEmr4k5OpMiNOyOGuZnLZ4xU3VOdBKLr/r6yLHa9dzTXlneVb5TvKRV603hv7DmlLPCnGk0WIqtHFojkRcP66k6dqO/lJbHLGfLyQp3eABzrb1hzms+HPt7MwoyGTYI4I60SMJ1bJDY5Qmn2lrudJUHulAx2FhGIQNdPkLaWqYt2JNoo3/npn2kZIdQp89x4zDLa1qCK2CmFZ0aWBjQza1Ag7ZLRJ9GT7u/wP1Wo4ypvz6bZ6JYunf5TQMzST3GeRP0kooHHkAwV1zjjv7if6vEQyqVrJAyWtbBXvU14VMocU0KXRPXHfrzVbV8MGCBlXFf/RQanS8Ntha0xSosMBQomaGOJi3KtBZxb1EPzBEqDlUhGGAKorPBE8n/Tks7g3Cpa7Oo2Og5YqGXUWCEqbk5P7Mk2zbg2kXIgpuUKhTFZqIS2WJh6P2ZS1ht097wS56W0OqLjuYSXKxTMmzIXh0e0VoqntgA/3QsttLN6ZdeMdXYHODhvD9
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB4138.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(396003)(346002)(376002)(136003)(110136005)(83380400001)(86362001)(54906003)(36756003)(5660300002)(33656002)(2616005)(316002)(166002)(8936002)(8676002)(186003)(76116006)(53546011)(6506007)(91956017)(6512007)(6486002)(66476007)(66556008)(64756008)(71200400001)(66446008)(66946007)(478600001)(2906002)(4326008)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: suzcycYZ5W8Tjo51ziKL7t0x4OQrAljviONHChVEETQAs9NdKT316Hqwp6APQIIgeu1wgSQ+LZioAU/LlrmdSnOH+6/rJ+X/dRWNRjVkpwHiu6QCzWvRoq5EwJ2058/B9W+yKHWlUfupq7skVMk0Tz/RYEKq7vh3ZHetN/jcubfzBdKbCDP8nhsQTHinSAUlPp8PuOXkCPtCVd5josaeVSfozZtghHmZ8m1XHDcev1s8l4I+AmX1QZbpdjTNKvngeiyHyIq52bLR3bKlpuxAgsoXIQZoMZeeuTnF2gvLMKuANgufo2W0xwrtkM1tWHYFwEcS3SB1bIJzPQrrhUbiL10qT2rpaXqRWePo+8rEnCV0nMfuny9J94Bd2XL1LqONFqDw1vL13ZpzeHjdPji/krN67D15Y1dAu3COAx9hpxv2Mm+vxNgKzAoTCWIZ/+9ZZf/VJNNByWsNPUCBdOgWpU5RABOF5cy4qu7UQYBDqKUDIaQhDh+KnPVCfEjDC2s3x1N/aiQaVlnFP6cc++w8XjUeUq2vXDsKjKrfAJMhAR/T1diZEZ8iffZyf+vHjG1EDIdHcsI1oMhVuRcQNBGgvG+4F9Tpwlf8kKWIsfVEVWyOQdnge8ebR4heIK1WHjm3VsCXWaBdCJCTrQfUqRK+xHpycMr6ywfWFgbFYK5pWhv1r6RPVPp8ZbPLE3xtjypuVUCN1C+cIZBBTwJgSY1k1C5uSMXanz533wNHmSTy68K+HlsUrO413T/Nj842PwZnRZnZd0dm/FpgrRO4O1I3tz1zM+FWyZUhAkk8krb4j0eGX0Jxh2jiI2ErdiS5Eff/XY/wv6RO5dv042qnw0fvZzt4HwmHzjLgief8NEU2a3tVgBPyJ2zYi51DbiRzKSwhWKNNViD8zLYJILuLyqcZohz4wzBeH5qbM/JQfaLVaan+D2yeKBSIb2ZArQClCN1qNgu+XTi4e6zduSTbIUvhvw1DbdQaHOpYIUSvg9v5a9m/o5/6+AikFqO3Zi3j0Gm631k/99XLLDzES82trtuf58B7IhMrhM5FenET0uxdgUxei+J7XlY5RLFJEQK11uPFUZJLM+bpithMFv90RAGy0r0mm/D9CvYBPFsbl3+nAw5yXstyexLuAjofFFND9Jz9nk4ic0mcaBPPsCexuEnhtFeuRXGXNZ/BObEs/u85IARVYaPuhJwoHt2Wlatz3PIMaxQkMKjyFRPhgQ3MqGFQr2dWzfHjgQTsyeb2ACeUcTeFbVUA/xrwzKCIVETRbz+yGKmYgLpijdU+ys7wQmt1fR5kUnINLO6Rv1AwCN/zxBFJlGJMixHK94k2chvR0dXFTsRYDB7nAhza509fE44k9u+o1cOve8Bu2LJ+nAmhCc7u7E1rXdONwJdYbHbJyhnt4g2tIFZA7XslH+fszF6lJg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_E338C9626BCC491696FBDC99FFDE6F14junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB4138.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 213f61fa-9476-4b1e-b717-08d8e3ce7710
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2021 14:11:57.1318 (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: Cn+zScCxnfTglOtSXb+wO4EP9Pd6qA7AJTR5F/lsld2BqqCZuh4Vufuc3vNRDo8z7GvKgG+YhBPMkni66h2Ftg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB3946
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-10_08:2021-03-10, 2021-03-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 bulkscore=0 phishscore=0 clxscore=1011 impostorscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103100070
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/XlKpIRyLQl17PQsjZGl6ehzdNQQ>
Subject: Re: [mpls] On the use of GAL in MPLS-SFC OAM
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Mar 2021 14:12:38 -0000

Thanks Greg for following up and all for the clarifications.
Rereading rfc6423, I understand the presence of a GAL (anywhere in the stack) is merely to indicate an ACH immediately follows the BoS (at least my reading of it).

“

      is replaced by:

         In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
         LSPs, Concatenated Segments of LSPs, and with Sections, and MAY
         be used with PWs.  The presence of a GAL indicates that an ACH
         immediately follows the MPLS label stack.
“


In Greg’s proposal, my understanding is the presence of GAL in the label stack carries additional semantics (depending on type of previous label), quoting
“GAL: G-ACh Label. If the GAL immediately follows the SFC Context label, then the packet is recognized as an SFP OAM packet.”

Hence, this may be updating rfc6423?

Regards,
Tarek


On 3/10/21, 8:14 AM, "Adrian Farrel" <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:

Top post.

Yes, I don’t think there was ever a requirement that only one GAL be present. It was a result of requiring GAL as BoS.
When that requirement went, multiple GALs could be present.

I believe that one of the issues was to allow OAM along an LSP in the hierarchy without requiring dive to BoS to hunt for GAL.

Greg’s use cases are new in the sense that MPLS-SFC OAM is new.

Cheers,
Adrian

From: mpls <mpls-bounces@ietf.org> On Behalf Of Greg Mirsky
Sent: 09 March 2021 20:34
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls <mpls@ietf.org>; draft-lm-mpls-sfc-path-verification@ietf.org; MPLS Working Group <mpls-chairs@ietf.org>
Subject: Re: [mpls] On the use of GAL in MPLS-SFC OAM

Hi Stewart,
thank you for your comments and questions. Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Mar 9, 2021 at 9:49 AM Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>> wrote:


On 9 Mar 2021, at 17:05, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Tarek,
thank you for your comment on our draft at the MPLS WG meeting earlier this week. If I captured your comment correctly, you've pointed out that RFC 5586 defined that GAL MUST be at the bottom of the stack. And, because of that, it can appear only once in the label stack. I agree with you that that is the definition of GAL in RFC 5586 but I have several clarifications to the current GAL definition:
·         firstly, the requirement that GAL MUST be at the bottom of the stack in RFC 5586 is applicable only to the MPLS-TP network. For other MPLS environments RFC 5586 "places no restrictions on where the GAL may appear within the label stack". Obviously, for any MPLS environment, the presence of GAL in the label stack means that ACH immediately follows the bottom-of-the-stack label.
·         also, will note that RFC 6423 updated the requirement of where in the label stack GAL is placed to the following:
         In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
         LSPs, Concatenated Segments of LSPs, and with Sections, and MAY
         be used with PWs.  The presence of a GAL indicates that an ACH
         immediately follows the MPLS label stack.
As I interpret the text, the requirement for placing GAL as BoS in the MPLS-TP environment has been lifted by RFC 6423.

To conclude, I don't find in the current normative documents related to the use of GAL any requirements to use it only as the BoS label or that it cannot appear more than once in the label stack. Perhaps I've missed something in documents that specify the applicability of GAL. I much appreciate your thoughts, comments on the use of GAL proposed in our draft

Greg

I can see that RFC6423 lifts the restriction on where the GAL may me placed in the stack, although I cannot work out from the text and cannot remember why we lifted the restriction.

What I cannot see is a lifting of the restriction that GAL can only appear once in the label stack.
GIM>> I couldn't find an explicit requirement that GAL must appear only once in a label stack. I think that that limitation was the logical consequence of the requirement included in RFC 5586 for the MPLS-TP network. Once the requirement to place GAL at the BoS removed, I cannot find any normative text to suggest that GAL cannot appear more than once in the label stack.

I am not quite sure I understand why you would need it more than once.
GIM>> This is resulting from RFC 8595<https://tools.ietf.org/html/rfc8595> that defines MPLS-SFC for two modes - swapping and stacking. For MPLS-SFC OAM, we propose using GAL in each Basic Unit of the MPLS label stack for SFC. Thus, in the stacking mode of MPLS-SFC GAL appears as many times as many basic units are present in the label stack.
If you find a GAL and need to access the ACH as a result, you need to be able to find the BOS. If you can find BOS then you could find the GAL at the BOS.
GIM>> I think that there could be a problem for some systems to inspect the label stack of every MPLS packet whether there's GAL and the bottom of the stack. Finding GAL as the next label, in our opinion, avoids that unnecessary lookup. Besides, systems can access only a certain number of labels in the fast path. For some systems that number is relatively small.

Why do we need to have the GAL in the packet more than once, and why not at BOS?
GIM>> I hope that we've explained the use case in our draft-lm-mpls-sfc-path-verification<https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification/>. Much appreciate your questions and comments on the draft.

Thanks

Stewart




Juniper Business Use Only