Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04

[Mach Chen <[e-mail]>]

Hi Greg,

Yes, I agree that heterogeneous environment scenario should be supported. Even if every node support the iOAM function, there may be requirements to specify partial nodes of an LSP to enable iOAM function. If so, scanning the label stack seems the only option.

Best regards,
Mach

From: Greg Mirsky [mailto:[e-mail]]
Sent: Friday, January 8, 2021 6:31 AM
To: Mach Chen <[e-mail]>
Cc: Loa Andersson <[e-mail]>; Stewart Bryant <[e-mail]>; Rakesh Gandhi (rgandhi) <rgandhi=[e-mail]>; mpls <[e-mail]>; [e-mail]; mpls-chairs <[e-mail]>
Subject: Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04

Hi Mach,
if I may extend the parallel with the solution described in RFC 8169, one of the challenges to be addressed was supporting a heterogeneous environment. In such an environment, the next RTM-capable LSR might not be the immediate downstream but several hops down. I suspect that the IOAM Hop-by-hop tracing option might be introduced gradually and thus the heterogeneous environment scenario should be supported by the proposed solution.
What do you think?

Regards,
Greg

On Thu, Jan 7, 2021 at 12:08 AM Mach Chen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Loa,

It depends where to put the (e)SPL and how to process the eSPL. If we define an eSPL and always put the eSPL on the top of the label stack. It means when sending a packet to next LSR, an eSPL will be put on the top of the stack, when the next LSR received the packet, the eSPL indicates iOAM related process needed, then pop off eSPL and process the next label that will result in forwarding the packet to the next LSR. When sending the packet to next LSR, an eSPL will be put back on the top of the stack. It just likes popping off two labels and pushing one label back. But this requires that all the LSRs along the packet MUST know how to process the eSPL, otherwise, the packet may be discarded.

Best regards,
Mach

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Thursday, January 7, 2021 1:13 PM
> To: Mach Chen <[e-mail]<mailto:[e-mail]>>; Greg Mirsky
> <[e-mail]<mailto:[e-mail]>>
> Cc: Stewart Bryant <[e-mail]<mailto:[e-mail]>>; Rakesh Gandhi (rgandhi)
> <rgandhi=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>; mpls-chairs <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
>
> Maach,
>
> If it is a requirement from iOAM to do hop by hop processing, then the SPL/eSPL
> is a very blunt tool, there is is always a risk that the (e)SPL label that indicate
> the special behavior is below the maximum stack depth that can be scanned.
>
> Right?
>
> If we create a FEC that says "this packet has a hop by hop processing
> requirement, go find the ACH-header immediately after the label stack to see
> what you need to do." That would not solve the immediate problem but also be
> useful for the future.
>
> /Loa
>
>
> On 07/01/2021 11:50, Mach Chen wrote:
> > Hi all,
> >
> > IMHO, I think the key issue is that there is no hop-by-hop option in
> > MPLS, but the iOAM requires that.
> >
> > There are three potential options:
> >
> > 1)Scan the stack and find the (e)SPL label that indicate the special
> > behavior;
> >
> > 2)Introduce an (e)SPL and always keep it on the top of the label
> > stack;
> >
> > 3)Use the way as Stewart suggested, a new FEC, just like the SFL;
> >
> > Best regards,
> >
> > Mach
> >
> > *From:*Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
> > *Sent:* Thursday, January 7, 2021 11:30 AM
> > *To:* Loa Andersson <[e-mail]<mailto:[e-mail]>>
> > *Cc:* Stewart Bryant <[e-mail]<mailto:[e-mail]>>; Rakesh Gandhi
> > (rgandhi) <rgandhi=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>;
> > [e-mail]<mailto:[e-mail]>; mpls-chairs <[e-mail]<mailto:[e-mail]>>
> > *Subject:* Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
> >
> > Hi Loa, et al.,
> >
> > RFC 8169 uses TTL expiration to achieve processing at each RTM-capable
> > node. That approach creates a state in transient nodes and may not fit
> > with the "no state" paradigm of the Segment Routing.
> >
> > And I've got a question. AFAIK, the presence of ACH in an MPLS LSP is
> > indicated by GAL. Is there an intention to introduce another (E)SPL
> > for that?
> >
> > Regards,
> >
> > Greg
> >
> > On Wed, Jan 6, 2021 at 7:20 PM Loa Andersson <[e-mail]<mailto:[e-mail]>
> > <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
> >
> >     Stewart,
> >
> >     If we want to make sure that packets are processed at evey node, is the
> >     new FEC complementary to the ACH-header or an alternative?
> >
> >     /Loa
> >
> >     On 05/01/2021 00:30, Stewart Bryant wrote:
> >     >
> >     >
> >     >> On 4 Jan 2021, at 14:38, Rakesh Gandhi (rgandhi)
> >     >> <rgandhi=[e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>
> >     >> <mailto:rgandhi<mailto:rgandhi> <mailto:rgandhi<mailto:rgandhi>>=[e-mail]<mailto:[e-mail]>
> >     <mailto:[e-mail]<mailto:[e-mail]>>>> wrote:
> >     >>
> >     >> <RG> Yes, this is similar to the entropy label where a mid-point node
> >     >> needs to scan the label stack to find the indicator label. We can add
> >     >> some text to clarify this. There is already an optimization to use a
> >     >> different indicator label for HbH compared to E2E case to
> >     >> unnecessarily avoid parsing the IOAM data fields.
> >     >
> >     > The EL is entirely optional to process. It is no more than a hint to use
> >     > in ECMP and there is no architectural requirement to find it to operate
> >     > correctly.
> >     >
> >     > If iOAM is purely a option then you could scan the stack and hope that
> >     > you can reach down far enough to find it. Though there is a fight to
> see
> >     > who gets to be the lowest label in range of the forwarding parser.
> >     >
> >     > If you want to be sure that iOAM is processed HxH then you really
> need
> >     > to run it on a new FEC with that behaviour built into the FEC. That
> >     > would be the architected way of doing this in MPLS.
> >     >
> >     > - Stewart
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > mpls mailing list
> >     > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> >     > https://www.ietf.org/mailman/listinfo/mpls
> >     <https://www.ietf.org/mailman/listinfo/mpls>
> >     >
> >
> >     --
> >
> >     Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>
> >     Senior MPLS Expert [e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>
> >     Bronze Dragon Consulting             phone: [phone]
> >
> >     _______________________________________________
> >     mpls mailing list
> >     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> >     https://www.ietf.org/mailman/listinfo/mpls
> >     <https://www.ietf.org/mailman/listinfo/mpls>
> >
>
> --
>
> Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
> Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
> Bronze Dragon Consulting             phone: [phone]