Re: [mpls] On the use of GAL in MPLS-SFC OAM
Greg Mirsky <gregimirsky@gmail.com> Wed, 10 March 2021 18:19 UTC
Return-Path: <gregimirsky@gmail.com>
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 AD5A33A14F1; Wed, 10 Mar 2021 10:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, 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=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 IOiJhAefQH2e; Wed, 10 Mar 2021 10:19:02 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 59C553A14F5; Wed, 10 Mar 2021 10:19:02 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id v9so35161078lfa.1; Wed, 10 Mar 2021 10:19:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ycya2TCWj/fWkZlyE1NWM+2sEaCDaFC07aUGv14u8GY=; b=vaHjLF7UuEcL8JVdPFJFGPMDyF+YIfnSuiWxJc3LlPsIAZ8W8dlNICx5xMksncEmuC cZ6X6osQwVUC+FdWPh3l5Yzhhgc8NI1KekhnLB8FxhD4fRn019Pcnvft77u+aomEb7In FIJezcWZds6kshzFjwGSqG+yUHAjsaTiBk2f/il/OquMh9Wa5qCx5ZLaAY+xIEnUVVm+ TfrauE6PyM+Qkof7+7Dp7G7sUN01NFUCgxBMPTj03N2feBR1vWzQJpIE0vGkjdEBlGss eIDPaKG/NJmL0sLsWvzMUr/7PrsMF47vtDfF48l7xMs77eGR38waKNdn0CxHFSKKeLP1 e/PQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ycya2TCWj/fWkZlyE1NWM+2sEaCDaFC07aUGv14u8GY=; b=EX94HvbSXgZfIEu5Zcv2s36MGQ6IdMVTROdrGaW76GYM1yT/OQ1GrpHVJLc7wCrEEo UME8RabdbEabTyvrQMMnWu9QNqdxN+9TxgwTQ8mdntG0yDEPrkoygC6zNPaj3y2yGPQK 8ehSv4n+fOzYif8iJ9RQKKSYEVGlz7AGy/OqUG2a+eJDbrudTngLbkoUL7y2eCUzwsJC nIfKXPFqLhKRUL7b5U1RmaSEX7VasS+bHD9etw2yFdE+PfCQL37/p9BiwaHOEUdsrG21 ItyxgWydA1V1q/If5fSych+h4q5hCGBV9xHz7CrUv5G2zSNJH2j5CU+AIZV0pMidMXfZ 8gig==
X-Gm-Message-State: AOAM530ZMqG2Z6UFbpIhNmbk2CNk21xGu1/LGLlrGiOU3MqrOqOytgPY gCSiuYdaLj3SR+GOR84hOmsy9CWGXYcUDqSjk4o=
X-Google-Smtp-Source: ABdhPJxZ57OEg/TvwZv2Ti228W867NVVx6u7UGzL1v5CxrHTzYUo2l+EeMNjuLIaCv+CbnLlG5tttPwHzdFK66fFcEc=
X-Received: by 2002:a05:6512:108e:: with SMTP id j14mr2635209lfg.364.1615400338568; Wed, 10 Mar 2021 10:18:58 -0800 (PST)
MIME-Version: 1.0
References: <CA+RyBmXf_Nzn3GxW+1Q1LFjcQ8zUpR9YEMBGyQJ0ODJPcBtD3g@mail.gmail.com> <3688C3DB-2583-4A8D-A9F6-1AF2D05875D0@gmail.com> <CA+RyBmViEB0A-EG6x31E8wes+ytzaLosu4SNzFusOKDM+op8+Q@mail.gmail.com> <df91051eecaa45e89eb7f795b3e59213@huawei.com>
In-Reply-To: <df91051eecaa45e89eb7f795b3e59213@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 10 Mar 2021 10:18:47 -0800
Message-ID: <CA+RyBmWvq+yW5sqg7ED=rOYUoQ8gmzWsbwb2+r2H6LTfN2PyRQ@mail.gmail.com>
To: Italo Busi <Italo.Busi@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Tarek Saad <tsaad.net@gmail.com>, MPLS Working Group <mpls-chairs@ietf.org>, mpls <mpls@ietf.org>, "draft-lm-mpls-sfc-path-verification@ietf.org" <draft-lm-mpls-sfc-path-verification@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000059ba8b05bd32b374"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/FcIYJyv9o4RsOuJnJn_CdqqwSew>
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 18:19:06 -0000
Hi Italo, thank you for pointing out the text in RFC 5586 that I've missed. And I agree with you that RFC 6423 does not update RFC 5586 in that regard. I would like to briefly describe the use case in the scope of our proposal. RFC 8595 defined how MPLS can emulate NSH-based SFC. To achieve that, It introduced the basic unit of MPLS label stack that can be used in MPLS label swapping, MPLS stacking, or mixed modes. When we were analyzing OAM in MPLS-SFC using the basic unit, we came to realize that an OAM packet should traverse SFFs and avoid being sent to SFs. Similar behavior can be achieved with native NSH and it is described in more detail in draft-ietf-sfc-multi-layer-oam <https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/>. To emulate the same behavior in MPLS-SFC, we are proposing using GAL within the basic unit when the payload is an OAM packet under the G-ACh. To summarize, the draft draft-lm-mpls-sfc-path-verification <https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification/> proposes the update of RFC 5586 in regard to the number of GAL labels present in the MPLS stack but only for transporting OAM control packet under the G-ACh. I greatly appreciate all the comments and questions. Many thanks for the great discussion. Regards, Greg On Wed, Mar 10, 2021 at 6:16 AM Italo Busi <Italo.Busi@huawei.com> wrote: > Hi Greg, > > > > The second paragraph of section 4.2 of RFC5586 says: > > > > The GAL MUST NOT appear in the label stack when transporting normal > > user-plane packets. Furthermore, when present, the GAL MUST NOT > > appear more than once in the label stack. > > > > Actually, I am noting that replacing the text in section 4.2 of RFC5586 as > written in RFC6423, the paragraph would read a bit weird: > > > > 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. Where the GAL is at the bottom > > of the label stack (i.e., S bit set to 1), then it MUST always be > > followed by an ACH. > > > > I think the reason is that at the time RFC5586 was written, the only > application of GAL was at the bottom of the stack but the authors of > RFC5586 did not want to be too restrictive on future applications of the > GAL. > > > > Maybe some editorial clean-up in RFC6423 is needed but it looks like that > RFC6423 places no restriction on where the GAL would appear within the > label stack but adds the requirement that, independently on where the GAL > appears in the label stack, when the GAL is present, the ACH MUST follow > the bottom of the label stack. > > > > Anyway, RFC6423 does not remove the requirement for the GAL to appear only > once within the label stack. > > > > Italo > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* martedì 9 marzo 2021 21:34 > *To:* Stewart Bryant <stewart.bryant@gmail.com> > *Cc:* Tarek Saad <tsaad.net@gmail.com>; MPLS Working Group < > mpls-chairs@ietf.org>; mpls <mpls@ietf.org>; > draft-lm-mpls-sfc-path-verification@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 > <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 > > > > > >
- [mpls] On the use of GAL in MPLS-SFC OAM Greg Mirsky
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Stewart Bryant
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Greg Mirsky
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Adrian Farrel
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Tarek Saad
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Italo Busi
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Huub van Helvoort
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Tarek Saad
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Alexander Vainshtein
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Alexander Vainshtein
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Stewart Bryant
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Stewart Bryant
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Greg Mirsky
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Greg Mirsky
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Italo Busi
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Tarek Saad
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Italo Busi
- Re: [mpls] On the use of GAL in MPLS-SFC OAM Greg Mirsky