From nobody Tue Mar 9 09:49:32 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 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 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, 9 Mar 2021 17:49:24 +0000 In-Reply-To: Cc: Stewart Bryant , Tarek Saad , MPLS Working Group , mpls , draft-lm-mpls-sfc-path-verification@ietf.org To: Greg Mirsky References: X-Mailer: Apple Mail (2.3608.120.23.2.4) 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: Tue, 09 Mar 2021 17:49:30 -0000 --Apple-Mail=_A1259077-1027-4D0E-932E-8F6140B0F207 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 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 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 --Apple-Mail=_A1259077-1027-4D0E-932E-8F6140B0F207 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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


= --Apple-Mail=_A1259077-1027-4D0E-932E-8F6140B0F207--