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

[Greg Mirsky <[e-mail]>]

Hi Stewart,
thank you for your kind consideration of the proposal to use multiple GAL
in a stack in some scenarios.
I agree that it is more appropriate to have such an update with the
analysis and explanation of the rationale in a separate document. I'll
start, as you've suggested, and hope you and other participants of the
discussion join as co-authors.

Best regards,
Greg

On Wed, Mar 10, 2021 at 9:44 AM Stewart Bryant <[e-mail]>
wrote:

> In thinking about this, I don’t see why multiple GALs would do harm.
>
> If there is any doubt we should update RFC6423/RFC5586 to remove that
> doubt. Though I would prefer to do that in a document in its own right
> rather than as a side effect of another document.
>
> - Stewart
>
>
>
> On 10 Mar 2021, at 14:11, Tarek Saad <[e-mail]> 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).
>
> “
>
>       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" <[e-mail]> 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 <[e-mail]> *On Behalf Of *Greg Mirsky
> *Sent:* 09 March 2021 20:34
> *To:* Stewart Bryant <[e-mail]>
> *Cc:* mpls <[e-mail]>; [e-mail];
> MPLS Working Group <[e-mail]>
> *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 <[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
>
>
>
>
> Juniper Business Use Only
>
>
>