From nobody Tue Mar 9 09:06:38 2021 Return-Path: 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 EED993A0E43; Tue, 9 Mar 2021 09:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IS-1FfBMskhl; Tue, 9 Mar 2021 09:06:35 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AFA3A153E; Tue, 9 Mar 2021 09:06:03 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id f1so28270406lfu.3; Tue, 09 Mar 2021 09:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=4gI/wkUwHASDQw1DYEY+c/pA2si3AEUMXEk2qnIPQXU=; b=txJOFqdo0AA36Ftowpu/iTojcLkpIx4i22GiNopnWeQLYRX5+J8zn80yd32XZeUQ+a dai4vpRarr3xy334XZ+Tkl5seo6RrTYT0axn83ignemGcdGICI04gWRRZl66jtx87qnT sbdjJPAnOsPGv35BTCnexBdkuipWFd5iMu+L6Ky3i/x9pZd6Au+mwT2u3DvMrQXOKqj3 ai/HOoNt9lcFxKJTNe6J3jdjfgLJwIwWcw1yf3UzCNNyN7Pj89dKciHJXsApzkQ+HG7G 924O2r5vgHl7b2+XnqNzGtC7aUynfVlqzlh2E1ixdTExv/X1MFV+QQkh5vzzpYhfkLnZ xVkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=4gI/wkUwHASDQw1DYEY+c/pA2si3AEUMXEk2qnIPQXU=; b=F+hgS+2fDN0XXuG9UIlC3id/J7AClhraUOvamZXNKu7NXmJv9pa9Wx8uOeW0qMdRtq iHuLFmxxO5POSWkl1rwRNz4KN87ZSsqrLrv8a4e+N+e56q6LM+tHNDR10yhTaMvnVKkx KgqmRSWU2ofMFYyVqzPBBNaFcF1rnJesuq28Wtlu/ugS+I/gHIlIpRA6ljnSncdTajAV 2Dc4nLZiCGULHolHg47alpqNOpxGV//kK+tNsArAl2aIwT7KVHelUTiOTBGQBGIyf192 uzZ98E1mTI4j3leH7+GneyEqq7vv7+y1r5wbV6vlhNFrm4fzECpeP1WFz9fFPElBiOhD JV1Q== X-Gm-Message-State: AOAM532jFsY1Mmq7CE7laAPJyOmttzaGbH9sW+thJdCXKWFchOM5hrQ6 rLRNiCMZaEgstVSKNPXknS2Sa9IXFf1+iDx4U2uYWHL+9HCtlQ== X-Google-Smtp-Source: ABdhPJyyFSyT3hd14lCcxk1YYVVqZ1QMDJug4+YW1ma6F2o9EnrZVDwuKmHbQACiILMFQsMhsp0nqs2OHifq7qYE0Mo= X-Received: by 2002:a05:6512:2341:: with SMTP id p1mr18396648lfu.192.1615309560213; Tue, 09 Mar 2021 09:06:00 -0800 (PST) MIME-Version: 1.0 From: Greg Mirsky Date: Tue, 9 Mar 2021 09:05:48 -0800 Message-ID: To: Tarek Saad , MPLS Working Group , mpls Cc: draft-lm-mpls-sfc-path-verification@ietf.org, Greg Mirsky Content-Type: multipart/alternative; boundary="00000000000089f67805bd1d9030" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 17:06:37 -0000 --00000000000089f67805bd1d9030 Content-Type: text/plain; charset="UTF-8" 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. Regards, Greg --00000000000089f67805bd1d9030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tarek,
thank you for your comment on our draft at t= he 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 botto= m 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 environ= ments RFC 5586 "places no restrictions on where the GAL may appear wit= hin the label stack". Obviously, for any MPLS environment, the presenc= e=C2=A0of GAL in the label stack means that ACH immediately follows the bot= tom-of-the-stack label.
  • also, will note that RFC 6423 updated the r= equirement of where in the label stack GAL is placed to the following:
    • =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In MPLS-TP, the GAL MUST be used wit= h packets on a G-ACh on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LSPs, Concaten= ated Segments of LSPs, and with Sections, and MAY
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0be used with PWs.=C2=A0 The presence of a GAL indicates that a= n ACH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0immediately follows the MPLS lab= el 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. Perh= aps I've missed something in documents that specify the applicability o= f GAL. I much appreciate your thoughts, comments on the use of GAL proposed= in our draft.

Regards,
Greg
--00000000000089f67805bd1d9030--