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

From: Greg Mirsky <[email-masked]>
Date: Tue, 9 Mar 2021 09:05:48 -0800

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.

Regards,
Greg

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 9 Mar 2021 17:49:24 +0000

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 9 Mar 2021 12:34:06 -0800

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 <[email-masked]>
wrote:

> 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
>    - also, will note that RFC 6423 updated the requirement of where in
>    the label stack GAL is placed to the following:
>
> 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
> 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.
>
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
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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Mar 2021 13:14:42 -0000

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 <[email-masked]> On Behalf Of Greg Mirsky
Sent: 09 March 2021 20:34
To: Stewart Bryant <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; MPLS Working Group <[email-masked]>
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 <[email-masked] <mailto:[email-masked]> > wrote:

On 9 Mar 2021, at 17:05, Greg Mirsky <[email-masked] <mailto:[email-masked]> > wrote:

Hi Tarek,

*	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:

Greg

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.

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.

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

---

From: Tarek Saad <[email-masked]>
Date: Wed, 10 Mar 2021 14:11:57 +0000

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 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" <[email-masked]<mailto:[email-masked]>> wrote:

Top post.

Cheers,
Adrian

Hi Stewart,

Regards,
Greg

On Tue, Mar 9, 2021 at 9:49 AM Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

On 9 Mar 2021, at 17:05, Greg Mirsky <[email-masked]<mailto:[email-masked]>> 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.

Greg

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

---

From: Italo Busi <[email-masked]>
Date: Wed, 10 Mar 2021 14:16:12 +0000

Hi Greg,

The second paragraph of section 4.2 of RFC5586 says:

   The GAL MUST NOT appear in the label stack when transporting normal
   user-plane packets.  Furthermore, when present, the GAL MUST NOT
   appear more than once in the label stack.

Actually, I am noting that replacing the text in section 4.2 of RFC5586 as written in RFC6423, the paragraph would read a bit weird:

   immediately follows the MPLS label stack. Where the GAL is at the bottom

   of the label stack (i.e., S bit set to 1), then it MUST always be

   followed by an ACH.

I think the reason is that at the time RFC5586 was written, the only application of GAL was at the bottom of the stack but the authors of RFC5586 did not want to be too restrictive on future applications of the GAL.

Maybe some editorial clean-up in RFC6423 is needed but it looks like that RFC6423 places no restriction on where the GAL would appear within the label stack but adds the requirement that, independently on where the GAL appears in the label stack, when the GAL is present, the ACH MUST follow the bottom of the label stack.

Anyway, RFC6423 does not remove the requirement for the GAL to appear only once within the label stack.

Italo

From: Greg Mirsky [mailto:[email-masked]]
Sent: martedì 9 marzo 2021 21:34
To: Stewart Bryant <[email-masked]>
Cc: Tarek Saad <[email-masked]>; MPLS Working Group <[email-masked]>; mpls <[email-masked]>; [email-masked]
Subject: Re: [mpls] On the use of GAL in MPLS-SFC OAM

Hi Stewart,

Regards,
Greg

Hi Tarek,

Greg

Thanks

Stewart

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 10 Mar 2021 15:56:39 +0100

Hello Tarek,

You wrote:

> 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.

> 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.”
> 
> 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.
> 
> 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.
> 
> *From:* mpls <[email-masked]> *On Behalf Of *Greg Mirsky
> *Sent:* 09 March 2021 20:34
> *To:* Stewart Bryant <[email-masked]>
> *Cc:* mpls <[email-masked]>; 
> [email-masked]; MPLS Working Group 
> <[email-masked]>
> *Subject:* Re: [mpls] On the use of GAL in MPLS-SFC OAM
> 
> Hi Stewart,
> 
> On Tue, Mar 9, 2021 at 9:49 AM Stewart Bryant <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>         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:
> 
>             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
> 
>     placed in the stack, although I cannot work out from the text and
>     cannot remember why we lifted the restriction.
> 
> find any normative text to suggest that GAL cannot appear more than once 
> in the label stack.
> 
> 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 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 

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

---

From: Tarek Saad <[email-masked]>
Date: Wed, 10 Mar 2021 15:23:46 +0000

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" <[email-masked]> wrote:

    [External Email. Be cautious of content]

    Hello Tarek,

    Best regards, Huub.

    > <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8595__;!!NEt6yMaO-gk!Xv6V3fgWdfBjwyzWZWBIhuHhWAvbFpiJBqCQjOsbRuK5CT4SXAClLA4ofDiCBQ$ > that defines MPLS-SFC for two
    > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification/__;!!NEt6yMaO-gk!Xv6V3fgWdfBjwyzWZWBIhuHhWAvbFpiJBqCQjOsbRuK5CT4SXAClLA44EKILYg$ >.
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!Xv6V3fgWdfBjwyzWZWBIhuHhWAvbFpiJBqCQjOsbRuK5CT4SXAClLA5o_ig8BQ$
    >

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 10 Mar 2021 13:28:08 +0000

Adrian, Greg, Stewart and all,
I fully agree that with the requirement for GAL being the BoS label you may have as many GAL labels in the stack as you wish.

However, my understanding so far has been that GAL in the label stack simply means that the first 4 octets following the BoS label in the label stack represent the GACh header and should be treated as such. If this is correct, why having multiple GAL labels it the label stack would make any difference? There would still be just one BoS label and one GACh following it.

What, if anything, do I miss?
Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: mpls <[email-masked]> On Behalf Of Adrian Farrel
Sent: Wednesday, March 10, 2021 3:15 PM
To: 'Greg Mirsky' <[email-masked]>; 'Stewart Bryant' <[email-masked]>
Cc: 'mpls' <[email-masked]>; [email-masked]; 'MPLS Working Group' <[email-masked]>
Subject: Re: [mpls] On the use of GAL in MPLS-SFC OAM

NOTICE: This email was received from an EXTERNAL sender.

Top post.

Cheers,
Adrian

From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Mirsky
Sent: 09 March 2021 20:34
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; MPLS Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] On the use of GAL in MPLS-SFC OAM

Hi Stewart,

Regards,
Greg

Hi Tarek,

Greg

I am not quite sure I understand why you would need it more than once.
GIM>> This is resulting from RFC 8595<https://clicktime.symantec.com/3UwVLR43M5ixUnUSSE6h5UK6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8595> 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://clicktime.symantec.com/3W6Mw6Zq5Sfk4sWGBEeqYaL6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-lm-mpls-sfc-path-verification%2F>. Much appreciate your questions and comments on the draft.

Thanks

Stewart

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 10 Mar 2021 14:24:26 +0000

Tarek and all,
The proposal to treat GAL differently depending on whether it immediately follows the SFC Context label or not looks as a major and quite problematic change of RFC 6423 to me.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: mpls <[email-masked]> On Behalf Of Tarek Saad
Sent: Wednesday, March 10, 2021 4:12 PM
To: [email-masked]; 'Greg Mirsky' <[email-masked]>; 'Stewart Bryant' <[email-masked]>
Cc: 'mpls' <[email-masked]>; [email-masked]; 'MPLS Working Group' <[email-masked]>
Subject: Re: [mpls] On the use of GAL in MPLS-SFC OAM

“

      is replaced by:

Regards,
Tarek

Top post.

Cheers,
Adrian

Hi Stewart,

Regards,
Greg

Hi Tarek,

Greg

I am not quite sure I understand why you would need it more than once.
GIM>> This is resulting from RFC 8595<https://clicktime.symantec.com/3K8P26eBFXRRMZvacapKX7E6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8595> 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://clicktime.symantec.com/3PnVbZ4DiMCb1YMeXPH5YJ96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-lm-mpls-sfc-path-verification%2F>. Much appreciate your questions and comments on the draft.

Thanks

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Mar 2021 17:44:15 +0000

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 <[email-masked]> wrote:
> 
> On 3/10/21, 8:14 AM, "Adrian Farrel" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Top post.
>  
> On Tue, Mar 9, 2021 at 9:49 AM Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>>  
>> 
>>> On 9 Mar 2021, at 17:05, Greg Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>>> Hi Tarek,
> 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
>>  
>>  
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Mar 2021 17:52:27 +0000

Hi Huub,

> On 10 Mar 2021, at 14:56, Huub van Helvoort <[email-masked]> wrote:
> 

The GAL tells the forwarder  that there is an ACH at BoS. 

My interpretation is that any additional GAL says the same thing, and all of them refer to the same (single) ACH.

We are doing to be discussing this in the PALS Friday meeting, because it is only in the last few months that anyone has suggested that there would be more than one ACH, and we need to understand what the implications of such a change are both in the short term, and for the future of the MPLS protocol.

- Stewart

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Mar 2021 10:18:47 -0800

Hi Italo,
thank you for pointing out the text in RFC 5586 that I've missed. And I
agree with you that RFC 6423 does not update RFC 5586 in that regard.
I would like to briefly describe the use case in the scope of our proposal.
RFC 8595 defined how MPLS can emulate NSH-based SFC. To achieve that, It
introduced the basic unit of MPLS label stack that can be used in MPLS
label swapping, MPLS stacking, or mixed modes. When we were analyzing OAM
in MPLS-SFC using the basic unit, we came to realize that an OAM packet
should traverse SFFs and avoid being sent to SFs. Similar behavior can be
achieved with native NSH and it is described in more detail in
draft-ietf-sfc-multi-layer-oam
<https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/>. To
emulate the same behavior in MPLS-SFC, we are proposing using GAL within
the basic unit when the payload is an OAM packet under the G-ACh.
To summarize, the draft draft-lm-mpls-sfc-path-verification
<https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification/>
proposes
the update of RFC 5586 in regard to the number of GAL labels present in the
MPLS stack but only for transporting OAM control packet under the G-ACh.

I greatly appreciate all the comments and questions. Many thanks for the
great discussion.

Regards,
Greg

On Wed, Mar 10, 2021 at 6:16 AM Italo Busi <[email-masked]> wrote:

> Actually, I am noting that replacing the text in section 4.2 of RFC5586 as
> written in RFC6423, the paragraph would read a bit weird:
>
>
>
> I think the reason is that at the time RFC5586 was written, the only
> application of GAL was at the bottom of the stack but the authors of
> RFC5586 did not want to be too restrictive on future applications of the
> GAL.
>
>
>
> Maybe some editorial clean-up in RFC6423 is needed but it looks like that
> RFC6423 places no restriction on where the GAL would appear within the
> label stack but adds the requirement that, independently on where the GAL
> appears in the label stack, when the GAL is present, the ACH MUST follow
> the bottom of the label stack.
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* martedì 9 marzo 2021 21:34
> *Cc:* Tarek Saad <[email-masked]>; MPLS Working Group <
> [email-masked]>; mpls <[email-masked]>;
> [email-masked]
> <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.
>
> 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

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Mar 2021 10:23:36 -0800

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 <[email-masked]>
wrote:

> 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
>
>
>
> stack) is merely to indicate an ACH immediately follows the BoS (at least
> my reading of it).
>
> “
>
>       is replaced by:
>
>
> stack carries additional semantics (depending on type of previous label),
> quoting
> On 3/10/21, 8:14 AM, "Adrian Farrel" <[email-masked]> wrote:
>
> Top post.
>
> *Cc:* mpls <[email-masked]>; [email-masked];
> MPLS Working Group <[email-masked]>
> ·         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
> ·         also, will note that RFC 6423 updated the requirement of where

---

From: Italo Busi <[email-masked]>
Date: Wed, 10 Mar 2021 18:24:43 +0000

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:[email-masked]]
> Sent: mercoledì 10 marzo 2021 16:24
> To: [email-masked]; [email-masked]; 'Greg Mirsky'
> <[email-masked]>; 'Stewart Bryant' <[email-masked]>
> Cc: 'mpls' <[email-masked]>; [email-masked];
> 'MPLS Working Group' <[email-masked]>
> 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.
> 
> <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8595__;!!NEt6y
> MaO-
> gk!Xv6V3fgWdfBjwyzWZWBIhuHhWAvbFpiJBqCQjOsbRuK5CT4SXAClLA4ofDiC
> BQ$ > that defines MPLS-SFC for two
>     >     Why do we need to have the GAL in the packet more than once, and
> why
>     >     not at BOS?
>     >
>     > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-lm-
> mpls-sfc-path-verification/__;!!NEt6yMaO-
> gk!Xv6V3fgWdfBjwyzWZWBIhuHhWAvbFpiJBqCQjOsbRuK5CT4SXAClLA44EKIL
> Yg$ >.
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!
> !NEt6yMaO-
> gk!Xv6V3fgWdfBjwyzWZWBIhuHhWAvbFpiJBqCQjOsbRuK5CT4SXAClLA5o_ig8
> BQ$
>     >
> 
> 
>     --
>

---

From: Tarek Saad <[email-masked]>
Date: Wed, 10 Mar 2021 18:49:53 +0000

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" <[email-masked]> wrote:

    Tarek, Huub,

    Italo

---

From: Italo Busi <[email-masked]>
Date: Wed, 10 Mar 2021 19:05:27 +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

> Sent: mercoledì 10 marzo 2021 19:50
> To: Italo Busi <[email-masked]>; [email-masked];
> [email-masked]; 'Greg Mirsky' <[email-masked]>; 'Stewart
> Bryant' <[email-masked]>
> 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.
>     >     > modes - swapping and stacking. For MPLS-SFC OAM, we propose
> using
>     > GAL in

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Mar 2021 12:09:34 -0800

Hi Italo,
thank you for pointing out to RFC 7026. It might be useful to our
discussion on Friday to look at the use of ACH and TLV defined for
Residence Time Measurement in RFC 8169
<https://datatracker.ietf.org/doc/rfc8169/>.

Regards,
Greg

On Wed, Mar 10, 2021 at 11:05 AM Italo Busi <[email-masked]> wrote:

> > As to your question, I thought the ACH TLV header has a length field
> (e.g.
> > RFC5586 section 3)?
> >
> > Regards,
> > Tarek
> >
> >     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
> >
> >     > Cc: 'mpls' <[email-masked]>;
> [email-masked];
> >     > 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
> >     >     > Rereading rfc6423, I understand the presence of a GAL
> (anywhere in
> > the
> >     >     >           LSPs, Concatenated Segments of LSPs, and with
> Sections, and
> > MAY
> >     >     >
> >     >     > In Greg’s proposal, my understanding is the presence of GAL
> in the
> > label
> >     >     > “GAL: G-ACh Label. If the GAL immediately follows the SFC
> Context
> > label,
> >     >     > thank you for your comments and questions. Please find my
> notes in-
> >     > lined
> >     >     >         On 9 Mar 2021, at 17:05, Greg Mirsky <
> [email-masked]
> >     >     >         <mailto:[email-masked]>> wrote:
> >     >     >
> >     >     >         Hi Tarek,
> >     >     >
> >     >     >         thank you for your comment on our draft at the MPLS
> WG
> > meeting
> >     >     >         pointed out that RFC 5586 defined that GAL MUST be
> at the
> > bottom
> >     >     >         means that ACH immediately follows the
> bottom-of-the-stack
> > label.
> >     >     >
> >     >     >                   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
> >     >     >     I can see that RFC6423 lifts the restriction on where
> the GAL may
> > me
> >     >     >     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
> >     >     > 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.
> >     >     >
> > <
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8595__;!!NEt6y
> >     > MaO-
> >     >
> >     >     > mode of MPLS-SFC GAL appears as many times as many basic
> units
> > are
> >     >     > 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
> >     >     > 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?
> >     >     >
> >     >     > <
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> > lm-