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

Stewart Bryant <stewart.bryant@gmail.com> Tue, 09 March 2021 17:49 UTC

Return-Path: <stewart.bryant@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 314F73A149A; Tue, 9 Mar 2021 09:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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 zGKXe403uTKC; Tue, 9 Mar 2021 09:49:28 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 85BA03A1499; Tue, 9 Mar 2021 09:49:28 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id l12so17374783wry.2; Tue, 09 Mar 2021 09:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RDjScF4mI/Cjpb0wOu5piOaLIJXor65ieEJVJmxa/ng=; b=RWQetPYwe/iqVrBwPgR6DvYvMExvAo3hVkO9BsBBJN2nsnPi0KZpepFYati1RPIUxy h8aS92SfjLqMDs9hMV+3A28dRzQZ1DsmC8vPC4mQmc6dmFYRtAt+qRtqJsKIfbEzQURE uAtCHjTuA37jwVyk8t6sGZZ4P3yF7WciZwGhdmUmZ7T2Fn+ggLGWtONrrjq00Ea4K+6b pAl1opjzVQ+QMyhc97wB88glw3SYfGO+xOHG2g52Sof0hqKLicNqFIb4VoeT3OuQYuCd SIZkp2s5pAUhUuqKY8qn9XpVbS1hu3/i97IXQ5LGyZIXvZgW9rCGHyFmFlE76/rofvBx oRfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RDjScF4mI/Cjpb0wOu5piOaLIJXor65ieEJVJmxa/ng=; b=af0fH1JkA3UYaFhA7ronXcZITOg2QFFR+oCoOJ/q+2JZkHh/h1rhjO0hjx5vk9CrLi Z7ETWrWK3N2MR7hK3L4d+1hWH47nAwHWFux12iUIEsuaXUqw/tQ/evPHt/hoc4nNTU3+ 1raeW3BA7oS/jjOwus7Ilbsp+lVcC+3QBaF2YKwkJS4zqpEJdRjOpO5V1jNWH+Q3tTRT kEIfyQv8JXoqAAeZ1T6XZ09IANPBNf2oqq/rQaxAcIO036XXhxi6DeJR8ZuIYC9BggMv BgP2J7VspxVhJXcBKXRWY2zu9Or2CS2Vo3I1M8pe2dZsKy93UNMQm30gY3VxXni7GtJf Egwg==
X-Gm-Message-State: AOAM5333WpSbeK5dFjW2pFjHCVUr1GIm8uzXruOIt2kyft5oDGAw4sxu ymCIsYHnRvHPl8Z408Wlpvs=
X-Google-Smtp-Source: ABdhPJxyT449iHLtDdH35m15w61oy2OLlO7tIjyMD3CVmJDZgeTOdT27pJNcl7dYLU51CeVn7xSNnw==
X-Received: by 2002:adf:d4d0:: with SMTP id w16mr19981596wrk.406.1615312165596; Tue, 09 Mar 2021 09:49:25 -0800 (PST)
Received: from [192.168.8.102] ([185.69.144.186]) by smtp.gmail.com with ESMTPSA id u4sm25312898wrr.37.2021.03.09.09.49.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Mar 2021 09:49:25 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <3688C3DB-2583-4A8D-A9F6-1AF2D05875D0@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1259077-1027-4D0E-932E-8F6140B0F207"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 09 Mar 2021 17:49:24 +0000
In-Reply-To: <CA+RyBmXf_Nzn3GxW+1Q1LFjcQ8zUpR9YEMBGyQJ0ODJPcBtD3g@mail.gmail.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
To: Greg Mirsky <gregimirsky@gmail.com>
References: <CA+RyBmXf_Nzn3GxW+1Q1LFjcQ8zUpR9YEMBGyQJ0ODJPcBtD3g@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/kNCYjr6Lg6vGlmiBmrU1yb8odjg>
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: Tue, 09 Mar 2021 17:49:30 -0000


> 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.

I am not quite sure I understand why you would need it more than once. 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.

Why do we need to have the GAL in the packet more than once, and why not at BOS?

Thanks

Stewart