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

[Italo Busi <[e-mail]>]

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:[e-mail]]
> Sent: mercoledì 10 marzo 2021 16:24
> To: [e-mail]; [e-mail]; 'Greg Mirsky'
> <[e-mail]>; '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
> 
> 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" <[e-mail]> 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" <[e-mail]
>     > <mailto:[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]
>     > <mailto:[e-mail]>> wrote:
>     >
>     >         On 9 Mar 2021, at 17:05, Greg Mirsky <[e-mail]
>     >         <mailto:[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://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
>     > [e-mail]
>     >
> 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