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

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://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
> 
> 
> Juniper Business Use Only
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 
================================================================
Always remember that you are unique...just like everyone else...