From nobody Wed Mar 10 05:14:52 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 76A0F3A0B55; Wed, 10 Mar 2021 05:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 olF1hJygfWns; Wed, 10 Mar 2021 05:14:48 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 DBF8E3A0BD5; Wed, 10 Mar 2021 05:14:47 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12ADEcPi006160; Wed, 10 Mar 2021 13:14:44 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6C5E122040; Wed, 10 Mar 2021 13:14:44 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 601052203C; Wed, 10 Mar 2021 13:14:44 +0000 (GMT) Received: from LAPTOPK7AS653V ([84.93.2.123]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12ADEgWq002584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Mar 2021 13:14:43 GMT Reply-To: From: "Adrian Farrel" To: "'Greg Mirsky'" , "'Stewart Bryant'" Cc: "'mpls'" , , "'MPLS Working Group'" References: <3688C3DB-2583-4A8D-A9F6-1AF2D05875D0@gmail.com> In-Reply-To: Date: Wed, 10 Mar 2021 13:14:42 -0000 Organization: Old Dog Consulting Message-ID: <0a4201d715af$5605f4d0$0211de70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A43_01D715AF.5607C990" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGvdTHTOtFswP+ZExhrpbX3DyDVaQK+wyhHA25DU4+qmwi2cA== X-Originating-IP: 84.93.2.123 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26020.007 X-TM-AS-Result: No--25.352-10.0-31-10 X-imss-scan-details: No--25.352-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26020.007 X-TMASE-Result: 10--25.351900-10.000000 X-TMASE-MatchedRID: OoEa6u7Uk5/uYusHgJkgymjJpufOqOIA8f3rOEwXzqeuBGQ0NzLWHPu0 JjibnX7jgXaxs/ngYK17eJWDenhDKKo2fOuRT7aaeLycN/G5ABO6quq7yusU2orqnYTxkVFKSbV pdCGpjwjrb+w7UF/yRWMFwILfD7YgDOs94g784gdIxFsMLu9ebLV5fSMRD1zqtPZ0go2hmmkVgI 0fS7eHxdZxIWPsCQYqyKBj9cXyLBK628cXbnOhT/g/s23WPBIpeWzr1vNAb+DQAhvnsK0MA2Al8 GZxTJZ8D4nMYtb6QhDuKpZZZkPBClkxnoxnQfVSChdI4sLlrjg4i81d4UW1MiOjy9RAKHrNZ73W rChDH0jmkMFgQQhR9gFXmKyQ1CGn8irf7wNB3Sgm4lf0t+giOLdG8whTbT2cjmUqFV0Rb1OH1rm F18SOTOMKmonJ4fKzM3VW+dKiADr1lJyvCKVZlJvqLprrkMW2OzHFPz3dROKbhw5LD1xrg07tug qPK2h+Op8+a2ibNcnsAGjS6lxxKjahjZPEodkX+ZfOn+32vrCntCxzpjT3tdyaYH9u+yrxhvc1n dOPlN1THL4ma9fp31O7V0JC3rK8KpEngz2rs68O9z+P2gwiBXuUPOHxn4SGKx1/iTUIGDKZAtc9 PmlQApsoKe6uvH9WjUwpeGQw6uywVIp8Y8imtVbLj6oPrALZpjfLp08U3/U7fUAhHHRznRZn42C 5xjIaSaVfaxxV94+zMJ0yoJG7DsG0UNgaZpYq2gp+A6golza2M1wsSbtrkfdIm8S+G8+gpL7GIT cGzGNPlNWvPMXFkPCDFvXZFmYywpU1WSBl38h9LQinZ4QefK9dKZJ2Vxiasuf7RWbvUtwa3uZ27 iW8Tj/cZn50ezHqi2QFaYS1v22rEHfaj14Zyf+K1r6Y/VHIYxp7DpfVK19+pSrUoIEzUbJWWc9n Y2ezwSIVCsTlaQHw4I8Fdhp/cw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 13:14:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A43_01D715AF.5607C990 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Top post. =20 Yes, I don=E2=80=99t 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. =20 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. =20 Greg=E2=80=99s use cases are new in the sense that MPLS-SFC OAM is new. =20 Cheers, Adrian =20 From: mpls On Behalf Of Greg Mirsky Sent: 09 March 2021 20:34 To: Stewart Bryant Cc: mpls ; draft-lm-mpls-sfc-path-verification@ietf.org; = MPLS Working Group Subject: Re: [mpls] On the use of GAL in MPLS-SFC OAM =20 Hi Stewart, thank you for your comments and questions. Please find my notes in-lined = below under the GIM>> tag. =20 Regards, Greg =20 On Tue, Mar 9, 2021 at 9:49 AM Stewart Bryant > wrote: =20 On 9 Mar 2021, at 17:05, Greg Mirsky > wrote: =20 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. =20 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 =20 Greg =20 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. =20 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. =20 I am not quite sure I understand why you would need it more than once.=20 GIM>> This is resulting from RFC 8595 = 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. =20 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 = = . Much appreciate your questions and comments on the draft.=20 =20 Thanks =20 Stewart =20 =20 ------=_NextPart_000_0A43_01D715AF.5607C990 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Top post.

 

Yes, I = don=E2=80=99t 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=E2=80=99s 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> = wrote:

 



On 9 Mar 2021, at 17:05, Greg Mirsky <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 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. Much appreciate your = questions and comments on the = draft. 

 

Thanks

 

Stewart

 

 

------=_NextPart_000_0A43_01D715AF.5607C990--