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

[Loa Andersson <[e-mail]>]

Eric,

Inline please.

On 08/01/2021 22:48, Eric Gray wrote:
> Loa,
> 
> 	As a clarification, did you mean to say "... would not _ONLY_ solve the immediate problem but also be useful for the future"?

   <blush>  yes
> 
> 	As a further clarification, does this align with Stewart's suggestion (using a separate FEC) below?

   I think so but have not discussed this with Stewart.
> 
> 	As a final question, is it not the case that having a separate FEC for any sort of OAM introduces a non-trivial risk of resulting in the OAM PDU being treated differently than a corresponding (possibly even otherwise identical) non-OAM PDU - thus reducing the usefulness of OAM?

    yes, that would be true both for both creating a new FEC or allocate 
a new eSPL, as soon as you have the requirement of the same forwarding

> 
> 	For instance, if you have two FEC entries - one for "normal" forwarding and another for "special" processing of PDUs intended to otherwise be forwarded identically - there is a possibility (not much point in speculating how likely/unlikely) that the NHLFE for the normal forwarding case might be lost at some point along an LSP and the loss not be detected because the "special" NHLFE remains...

    I hear you, but I would also like to hear from Rakesh and other OAM 
specialists about this. If there are two parallel FEC entries (mormal 
and special), there the normal does not need to be processed a every 
node. while the special does. That seems to be antagonistic requirements.

The lesson from MPLS-TP was "OAM traffic need to be forwarded the same 
way as the normal traffic." Unless you want to forward all traffic on 
the special FEC (or for that matter eSPL).

Anyone that can sort this out.

/Loa
> 
> --
> Eric
> 
> -----Original Message-----
> From: mpls <[e-mail]> On Behalf Of Loa Andersson
> Sent: Thursday, January 7, 2021 12:13 AM
> To: Mach Chen <[e-mail]>; Greg Mirsky <[e-mail]>
> Cc: mpls-chairs <[e-mail]>; mpls <[e-mail]>; [e-mail]; Rakesh Gandhi (rgandhi) <rgandhi=[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]]
>> *Sent:* Thursday, January 7, 2021 11:30 AM
>> *To:* Loa Andersson <[e-mail]>
>> *Cc:* 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 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]>> 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:rgandhi <mailto:rgandhi>=[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]>
>>      > 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]
>>
>>      _______________________________________________
>>      mpls mailing list
>>      [e-mail] <mailto:[e-mail]>
>>      https://www.ietf.org/mailman/listinfo/mpls
>>      <https://www.ietf.org/mailman/listinfo/mpls>
>>
> 

-- 

Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]