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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> On 9 Mar 2021, at 17:05, Greg Mirsky <[e-mail]> 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
>
>
>