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

Italo Busi <Italo.Busi@huawei.com> Wed, 10 March 2021 19:05 UTC

Return-Path: <Italo.Busi@huawei.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 2B5203A0D75; Wed, 10 Mar 2021 11:05:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 aERiqd0NK5ss; Wed, 10 Mar 2021 11:05:35 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6293A1608; Wed, 10 Mar 2021 11:05:35 -0800 (PST)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DwhFr62YCz67vqj; Thu, 11 Mar 2021 02:59:28 +0800 (CST)
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 20:05:27 +0100
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2106.013; Wed, 10 Mar 2021 20:05:27 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: 'Tarek Saad' <tsaad@juniper.net>, "huubatwork@gmail.com" <huubatwork@gmail.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Greg Mirsky' <gregimirsky@gmail.com>, 'Stewart Bryant' <stewart.bryant@gmail.com>
CC: 'mpls' <mpls@ietf.org>, "draft-lm-mpls-sfc-path-verification@ietf.org" <draft-lm-mpls-sfc-path-verification@ietf.org>, 'MPLS Working Group' <mpls-chairs@ietf.org>
Thread-Topic: [mpls] On the use of GAL in MPLS-SFC OAM
Thread-Index: AQHXFcF4CEqGJHvVxEeIv7uwuJqn7qp9iLIQ///3V4CAABGfAA==
Date: Wed, 10 Mar 2021 19:05:27 +0000
Message-ID: <16230ce6564949a594905df5e0f0e5b8@huawei.com>
References: <CA+RyBmXf_Nzn3GxW+1Q1LFjcQ8zUpR9YEMBGyQJ0ODJPcBtD3g@mail.gmail.com> <3688C3DB-2583-4A8D-A9F6-1AF2D05875D0@gmail.com> <CA+RyBmViEB0A-EG6x31E8wes+ytzaLosu4SNzFusOKDM+op8+Q@mail.gmail.com> <0a4201d715af$5605f4d0$0211de70$@olddog.co.uk> <E338C962-6BCC-4916-96FB-DC99FFDE6F14@juniper.net> <33e6a177-b453-d756-a933-d60e06e7c47c@gmail.com> <8FDBDA6F-F8C7-488C-BB28-8F33375BBC81@juniper.net> <0d6fa0fad2b54cf3951e4a1401db237b@huawei.com> <4812F297-8626-4109-B3D9-62159E2535FB@juniper.net>
In-Reply-To: <4812F297-8626-4109-B3D9-62159E2535FB@juniper.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.94.173]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/HYD-oHYFAcu6nYpI0tJ3ybICR-M>
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 19:05:38 -0000

Hi Tarek,

I understand we are not advocating multiple GACHs, just investigating if there are any technical issues

The Length field in the ACH TLV header is the Length of the complete set of ACH TLVs.

There is no length field for the G-ACh message that follow the ACH TLVs (see Figure 2).

Please be also aware that the definition of ACH TLVs has been retired in RFC7026.

Italo

> -----Original Message-----
> From: Tarek Saad [mailto:tsaad@juniper.net]
> Sent: mercoledì 10 marzo 2021 19:50
> To: Italo Busi <Italo.Busi@huawei.com>; huubatwork@gmail.com;
> adrian@olddog.co.uk; 'Greg Mirsky' <gregimirsky@gmail.com>; '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
> 
> Italo,
> 
> Just to be clear, I'm not personally advocating multiple GACHs be carried in
> same packet, but indeed this proposition was made on the mpls mail list
> earlier.
> As to your question, I thought the ACH TLV header has a length field (e.g.
> RFC5586 section 3)?
> 
> Regards,
> Tarek
> 
> On 3/10/21, 1:24 PM, "Italo Busi" <Italo.Busi@huawei.com> wrote:
> 
>     [External Email. Be cautious of content]
> 
> 
>     Tarek, Huub,
> 
>     Since GACH has no Length field, I am not sure how it is possible to put
> multiple GACHes in the same packet.
> 
>     How can a receiver know where the payload of the first GACH ends and the
> second GACH starts?
> 
>     Italo
> 
>     > -----Original Message-----
>     > From: Tarek Saad [mailto:tsaad@juniper.net]
>     > Sent: mercoledì 10 marzo 2021 16:24
>     > To: huubatwork@gmail.com; adrian@olddog.co.uk; 'Greg Mirsky'
>     > <gregimirsky@gmail.com>; '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
>     >
>     > Huub,
>     >
>     > Your comment is interesting. There may be discussion that perhaps will
>     > happen on Friday during the Joint MPLS/PALs/DETNET/SPRING session on
>     > feasibility of carrying multiple GACHs after the BoS.
>     >
>     > BTW, I'm not aware if anywhere it is described/dictated that there should
> be
>     > as many GALs as there are GACHs after the BoS, or if any order of visiting
> such
>     > multiple GACHs is mandated.
>     >
>     > I'll let Greg chime in to describe his usecase of multiple GALs.
>     >
>     > Regards,
>     > Tarek
>     >
>     > On 3/10/21, 9:57 AM, "Huub van Helvoort" <huubatwork@gmail.com>
> wrote:
>     >
>     >     [External Email. Be cautious of content]
>     >
>     >
>     >     Hello Tarek,
>     >
>     >     You wrote:
>     >
>     >     > Thanks Greg for following up and all for the clarifications.
>     >     >
>     >     > Rereading rfc6423, I understand the presence of a GAL (anywhere in
> the
>     >     > stack) is merely to indicate an ACH immediately follows the BoS (at
>     >     > least my reading of it).
>     >
>     >     If there is more than one GAL in the stack, then which ACH following
>     >     the BoS belongs to which GAL?
>     >
>     >     Best regards, Huub.
>     >
>     >     > “
>     >     >
>     >     >        is replaced by:
>     >     >
>     >     >           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.
>     >     >
>     >     > “
>     >     >
>     >     > In Greg’s proposal, my understanding is the presence of GAL in the
> label
>     >     > stack carries additional semantics (depending on type of previous
>     >     > label), quoting
>     >     >
>     >     > “GAL: G-ACh Label. If the GAL immediately follows the SFC Context
> label,
>     >     > then the packet is recognized as an SFP OAM packet.”
>     >     >
>     >     > Hence, this may be updating rfc6423?
>     >     >
>     >     > Regards,
>     >     >
>     >     > Tarek
>     >     >
>     >     > On 3/10/21, 8:14 AM, "Adrian Farrel" <adrian@olddog.co.uk
>     >     > <mailto:adrian@olddog.co.uk>> wrote:
>     >     >
>     >     > Top post.
>     >     >
>     >     > Yes, I don’t 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’s 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
>     >     > <mailto:stewart.bryant@gmail.com>> wrote:
>     >     >
>     >     >         On 9 Mar 2021, at 17:05, Greg Mirsky <gregimirsky@gmail.com
>     >     >         <mailto: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://urldefense.com/v3/__https://tools.ietf.org/html/rfc8595__;!!NEt6y
>     > MaO-
>     >
> gk!Xv6V3fgWdfBjwyzWZWBIhuHhWAvbFpiJBqCQjOsbRuK5CT4SXAClLA4ofDiC
>     > BQ$ > 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> lm-
>     > mpls-sfc-path-verification/__;!!NEt6yMaO-
>     >
> gk!Xv6V3fgWdfBjwyzWZWBIhuHhWAvbFpiJBqCQjOsbRuK5CT4SXAClLA44EKIL
>     > Yg$ >.
>     >     > Much appreciate your questions and comments on the draft.
>     >     >
>     >     >     Thanks
>     >     >
>     >     >     Stewart
>     >     >
>     >     >
>     >     > Juniper Business Use Only
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > mpls mailing list
>     >     > mpls@ietf.org
>     >     >
>     >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!
>     > !NEt6yMaO-
>     >
> gk!Xv6V3fgWdfBjwyzWZWBIhuHhWAvbFpiJBqCQjOsbRuK5CT4SXAClLA5o_ig8
>     > BQ$
>     >     >
>     >
>     >
>     >     --
>     >
>     >
> ================================================================
>     >     Always remember that you are unique...just like everyone else...
>     >
>     >
>     > Juniper Business Use Only
> 
> 
> Juniper Business Use Only