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

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 4 Jan 2021 14:38:01 +0000

Happy New Year!

Many thanks Mach for the MPLS-RT review. Please see comments inline with <RG>..

From: Mach Chen <[email-masked]>
Date: Wednesday, December 30, 2020 at 4:20 AM
To: mpls <[email-masked]>, mpls-chairs <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
Hi,

I've been asked to provide a pre-adoption MPLS-RT review of draft-gandhi-mpls-ioam-sr-04.

Below are my review comments:

1. I agree that it's more reasonable to leverage GAL/gACH with one or two new dedicated channel types for indicating the presence of iOAM data.

<RG> Yes, we will change to use ACH with IOAM Indicator Label, as agreed on another email thread.

2. In addition, the draft proposes to support both E2E and hop-by-hop (HBH) options. It's nature to use GAL/gACH or the IOAM Indicator Label (IIL) to indicate the presence of iOAM data.  But for HBH case, each intermediate LSR is supposed to process the iOAM data, and the GAL or IIL is put at the bottom of the stack, how does an intermediate LSR know whether there is iOAM data present and it should process the iOAM data?  To scan the whole label stack to find the GAL/IIL or through other means (e.g., put an indicator label on the top the label stack, this may require that each LSR need to pop the IIL label firstly, then process the next label, and put the IIL label back onto the top when forwarding the packet to the next hop) ?  For either way, this needs to be explicitly defined in the document.

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

Thanks,
Rakesh

I am OK with other parts of the draft, but the above comments would result in non-trivial updates to the draft, I would see an update before the WG adoption call.

Best regards,
Mach

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 4 Jan 2021 16:30:51 +0000

> On 4 Jan 2021, at 14:38, Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]> wrote:
> 

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

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 4 Jan 2021 22:41:27 +0000

Good to know.
Thanks Loa and Andy.

Tianran

________________________________

Sent from WeLink
发件人： Andrew G. Malis<[email-masked]<mailto:[email-masked]>>
收件人： Loa Andersson<[email-masked]<mailto:[email-masked]>>
抄送： Tianran Zhou<[email-masked]<mailto:[email-masked]>>;tom petch<[email-masked]<mailto:[email-masked]>>;mpls<[email-masked]<mailto:[email-masked]>>;mpls-chairs<[email-masked]<mailto:[email-masked]>>;draft-gandhi-mpls-ioam-sr<[email-masked]<mailto:[email-masked]>>
主题： Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
时间： 2020-12-31 19:49:13

Loa,

That's correct. It's the GAL that has the restriction, but not the ACH header.

Cheers,
Andy

On Thu, Dec 31, 2020 at 2:39 AM Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Tianran,

I'm not aware of such a restriction, if there were one wouldn't it have
been applicable to RFC 8169?

/Loa

On 31/12/2020 10:51, Tianran Zhou wrote:
> I have one concern on the usage of ACH.
> I am not sure if there is any restriction that Ach is only used for active/synthetic packet.
>
> Best,
> Tianran
> -----Original Message-----
> From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Loa Andersson
> Sent: Wednesday, December 30, 2020 12:13 PM
> To: tom petch <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; mpls-chairs <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> Subject: Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
>
> Tom, et.al<http://et.al>,
>
> On 28/12/2020 20:56, tom petch wrote:
>> However, I'd like to see more discussion on what we should do. In
>> particular I'd like to see a comment from the authors on this.
>>
>> <tp>
>>
>> Why not use ACH?
>
> I don't think there is anything in the thread the says "don't use ACH", what I want is just to tie up the last lose ends before going to decision.
>
> /Loa
>>
>> Tom Petch
>

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Loa Andersson <[email-masked]>
Date: Thu, 7 Jan 2021 11:20:19 +0800

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=[email-masked] 
>> <mailto:rgandhi=[email-masked]>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 6 Jan 2021 19:30:25 -0800

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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 7 Jan 2021 11:50:04 +0800

Greg,

(feeling the water) if we create a hop-by-hop FEC, that in itself could 
indicate the presence of the ACH-header, right?

/Loa

On 07/01/2021 11:30, Greg Mirsky wrote:
> node. That approach creates a state in transient nodes and may not fit 
> with the "no state" paradigm of the Segment Routing.
> On Wed, Jan 6, 2021 at 7:20 PM Loa Andersson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Stewart,
> 
>     <mailto:[email-masked]>
>      >> <mailto:rgandhi <mailto:rgandhi>=[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
>      >
> 
>     -- 
> 
>     Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
>     Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
> 

--

---

From: Mach Chen <[email-masked]>
Date: Thu, 7 Jan 2021 03:50:36 +0000

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:[email-masked]]
Sent: Thursday, January 7, 2021 11:30 AM
To: Loa Andersson <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]>; mpls <[email-masked]>; [email-masked]; mpls-chairs <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Stewart,

/Loa

On 05/01/2021 00:30, Stewart Bryant wrote:
>> <rgandhi=[email-masked]<mailto:[email-masked]>
>> <mailto:rgandhi<mailto:rgandhi>=[email-masked]<mailto:[email-masked]>>> wrote:
>>
> [email-masked]<mailto:[email-masked]>

--

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Thu, 7 Jan 2021 13:12:35 +0800

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:
> 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:[email-masked]]
> *Sent:* Thursday, January 7, 2021 11:30 AM
> *To:* Loa Andersson <[email-masked]>
> *Cc:* Stewart Bryant <[email-masked]>; Rakesh Gandhi (rgandhi) 
> <rgandhi=[email-masked]>; mpls <[email-masked]>; 
> [email-masked]; mpls-chairs <[email-masked]>
> *Subject:* Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
> 
> Hi Loa, et al.,
> 
>     >> <rgandhi=[email-masked] <mailto:[email-masked]>

--

---

From: Mach Chen <[email-masked]>
Date: Thu, 7 Jan 2021 08:08:46 +0000

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

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, January 7, 2021 1:13 PM
> To: Mach Chen <[email-masked]>; Greg Mirsky
> <[email-masked]>
> Cc: Stewart Bryant <[email-masked]>; Rakesh Gandhi (rgandhi)
> 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?
> 
> 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
> 
> 
> > *Cc:* Stewart Bryant <[email-masked]>; Rakesh Gandhi
> > (rgandhi) <rgandhi=[email-masked]>; mpls <[email-masked]>;
> > indicated by GAL. Is there an intention to introduce another (E)SPL
> > for that?
> >
> > Regards,
> >
> > Greg
> >
> <mailto:[email-masked]>
> <mailto:[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 7 Jan 2021 14:31:18 -0800

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 <[email-masked]> 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
>
> SPL/eSPL
> see
> > >     > you can reach down far enough to find it. Though there is a
> fight to
> > see

---

From: Mach Chen <[email-masked]>
Date: Fri, 8 Jan 2021 01:15:31 +0000

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:[email-masked]]
Sent: Friday, January 8, 2021 6:31 AM
To: Mach Chen <[email-masked]>
Cc: Loa Andersson <[email-masked]>; Stewart Bryant <[email-masked]>; Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]>; mpls <[email-masked]>; [email-masked]; mpls-chairs <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Loa,

Best regards,
Mach

> From: Loa Andersson [mailto:[email-masked]<mailto:[email-masked]>]
> To: Mach Chen <[email-masked]<mailto:[email-masked]>>; Greg Mirsky
> <[email-masked]<mailto:[email-masked]>>
> Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi (rgandhi)
> <rgandhi=[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; mpls-chairs <[email-masked]<mailto:[email-masked]>>
> > *From:*Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
> > *To:* Loa Andersson <[email-masked]<mailto:[email-masked]>>
> > *Cc:* Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi
> > (rgandhi) <rgandhi=[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>;
> > [email-masked]<mailto:[email-masked]>; mpls-chairs <[email-masked]<mailto:[email-masked]>>
> > On Wed, Jan 6, 2021 at 7:20 PM Loa Andersson <[email-masked]<mailto:[email-masked]>
> > <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> >     Stewart,
> >
> <mailto:[email-masked]<mailto:[email-masked]>>
> >     >> <mailto:rgandhi<mailto:rgandhi> <mailto:rgandhi<mailto:rgandhi>>=[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
> >     >>
> >     > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> <mailto:[email-masked]<mailto:[email-masked]>>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: Eric Gray <[email-masked]>
Date: Fri, 8 Jan 2021 14:48:25 +0000

Loa,

	As a clarification, did you mean to say "... would not _ONLY_ solve the immediate problem but also be useful for the future"?

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

	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?

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

--
Eric

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Thursday, January 7, 2021 12:13 AM
To: Mach Chen <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: mpls-chairs <[email-masked]>; mpls <[email-masked]>; [email-masked]; Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]>
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

--

---

From: Eric Gray <[email-masked]>
Date: Fri, 8 Jan 2021 14:51:02 +0000

Mach,

	I believe that always putting the eSPL on the top of the stack pretty much mandates ubiquitous (non-heterogeneous) deployment of devices that necessarily support iOAM - correct?

--
Eric

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Mach Chen
Sent: Thursday, January 7, 2021 3:09 AM
To: Loa Andersson <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: mpls-chairs <[email-masked]>; mpls <[email-masked]>; [email-masked]; Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]>
Subject: Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04

Hi Loa,

Best regards,
Mach

> 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?
> 
> 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
> 
> 
> > (rgandhi) <rgandhi=[email-masked]>; mpls 
> > <[email-masked]>; [email-masked]; mpls-chairs 
> > <[email-masked]>
> > 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
> >
> >     > If you want to be sure that iOAM is processed HxH then you 
> > really
> need

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 8 Jan 2021 21:16:45 +0000

Hi Loa,

If we create a hop-by-hop FEC (similar to synonymous label), I think the packet header encoding with ACH could look like following. I am not sure if there would be a need to also add GAL or E(SPL) just before the ACH header.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Synonymous IOAM Label(1)             | TC  |S|  TTL          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Synonymous IOAM Label(n)             | TC  |S|  TTL          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
   |0 0 0 1|Version|   Reserved    |          IOAM G-ACh Type      |  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
   | Reserved      | Block Number  | IOAM-OPT-Type |IOAM HDR Length|  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  I
   |                                                               |  O
   |                                                               |  A
   ~                 IOAM Option and Data Space                    ~  M
   |                                                               |  |
   |                                                               |  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
   |                                                               |
   |                                                               |
   |                 Payload + Padding                             |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,
Rakesh

From: Loa Andersson <[email-masked]>
Date: Wednesday, January 6, 2021 at 10:50 PM
To: Greg Mirsky <[email-masked]>
Cc: Stewart Bryant <[email-masked]>, Rakesh Gandhi (rgandhi) <[email-masked]>, mpls <[email-masked]>, [email-masked] <[email-masked]>, mpls-chairs <[email-masked]>
Subject: Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
Greg,

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Sat, 9 Jan 2021 13:23:02 +0800

Eric,

Inline please.

> 	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 (pos…

    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 mu…

    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

--

---

From: Mach Chen <[email-masked]>
Date: Mon, 11 Jan 2021 02:02:26 +0000

Hi Eric,

Yes, I am afraid that is the case.

Best regards,
Mach

> From: Eric Gray [mailto:[email-masked]]
> Sent: Friday, January 8, 2021 10:51 PM
> To: Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>; Greg
> Mirsky <[email-masked]>
> Cc: mpls-chairs <[email-masked]>; mpls <[email-masked]>;
> [email-masked]; Rakesh Gandhi (rgandhi)
> <rgandhi=[email-masked]>
> Subject: RE: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
> 
> Mach,
> 
> 	I believe that always putting the eSPL on the top of the stack pretty much
> mandates ubiquitous (non-heterogeneous) deployment of devices that
> necessarily support iOAM - correct?
> 
> --
> Eric
> 
> Cc: mpls-chairs <[email-masked]>; mpls <[email-masked]>;
> [email-masked]; Rakesh Gandhi (rgandhi)
> <rgandhi=[email-masked]>
> 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
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 11 Jan 2021 12:27:15 +0000

Yes that would work, but it means that you have to do three lookups at every hop and push three labels, and that is without searching for the ELI.

Those extra two labels reduce the number of SR labels you can push. If you need an EL that would mean that the legacy nodes that can only push 4 labels just burned their way through their limit without saying where the packet was going. 

We can obviously do this, but I worry that the number of SPLs on packets is getting out of hand.

When MPLS was first introduced there was a fundamental philosophy not to push any more labels than you needed and not to look further down the stack than you needed. We seem to have lost sight of that, and I am worried where it ends.

- Stewart

> On 7 Jan 2021, at 08:08, Mach Chen <[email-masked]> wrote:
> 
> Hi Loa,
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 11 Jan 2021 19:29:28 +0000

I have a slightly more fundamental question.

Why are we specifying this for sr?

Surely we should specify it for MPLS  and have SR inherit that?

Also what happens if the MPLS payload is a PW or Detnet or something else defined to be immediately below the bottom label?

Stewart

---

From: Mach Chen <[email-masked]>
Date: Tue, 12 Jan 2021 03:15:12 +0000

Hi Stewart, 

I share the concern regarding the eSPLs on the stack. 

The key issue of MPLS is that there is no common MPLS header and option filed, all operations only depend on labels. The cons and pros of such design are very obvious. This somehow results in the difficulties for innovations. 

Best regards,
Mach

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Monday, January 11, 2021 8:27 PM
> Cc: Stewart Bryant <[email-masked]>; loa Andersson <[email-masked]>;
> Greg Mirsky <[email-masked]>; Rakesh Gandhi (rgandhi)
> Yes that would work, but it means that you have to do three lookups at every
> hop and push three labels, and that is without searching for the ELI.
> 
> Those extra two labels reduce the number of SR labels you can push. If you
> need an EL that would mean that the legacy nodes that can only push 4 labels
> just burned their way through their limit without saying where the packet was
> going.
> 
> When MPLS was first introduced there was a fundamental philosophy not to
> push any more labels than you needed and not to look further down the stack
> than you needed. We seem to have lost sight of that, and I am worried where it
> ends.
> 
> - Stewart
> 
> 
> 
> > 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
> >> Cc: Stewart Bryant <[email-masked]>; Rakesh Gandhi
> >> 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
> >>>>> <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

---

From: Mach Chen <[email-masked]>
Date: Tue, 12 Jan 2021 03:18:44 +0000

Hi Stewart,

I guess your questions are for the authors of the draft, I will let the authors to answer the questions :-)

Best regards,
Mach

> Sent: Tuesday, January 12, 2021 3:29 AM
> Cc: Eric Gray <[email-masked]>; Loa Andersson <[email-masked]>; Greg
> Mirsky <[email-masked]>; mpls <[email-masked]>; Rakesh Gandhi
> (rgandhi) <rgandhi=[email-masked]>; mpls-chairs
> <[email-masked]>; [email-masked]
> Also what happens if the MPLS payload is a PW or Detnet or something else
> defined to be immediately below the bottom label?
> 
> Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 18 Jan 2021 15:38:53 +0000

Hi Mach

It is as much a question for the WG given that this is up for adoption.

In all other aspects MPLS-SR inherits everything from MPLS so why would it not do so here?

Also given that we want iOAM for SR why would we not want it for MPLS and associated technologies such as PW and VPN as well?

So my view is not to make a special case for SR and then have the complexity of introducing it to base MPLS, but instead solve this for MPLS and use it everywhere.

Is there something special about the SR case that I am missing here?

- Stewart

> On 12 Jan 2021, at 03:18, Mach Chen <[email-masked]> wrote:
> 
> Hi Stewart,
>

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Jan 2021 16:46:57 +0000

I agree with Stewart.

Yours Irrespectively,

John

Juniper Business Use Only

> From: mpls <[email-masked]> On Behalf Of Stewart Bryant
> Sent: Monday, January 18, 2021 10:39 AM
> Cc: mpls <[email-masked]>; mpls-chairs <[email-masked]>; draft-gandhi-
> [email-masked]; Rakesh Gandhi (rgandhi)
> [External Email. Be cautious of content]
> 
> 
> Hi Mach
> 
> Also given that we want iOAM for SR why would we not want it for MPLS and
> associated technologies such as PW and VPN as well?
> 
> So my view is not to make a special case for SR and then have the complexity of
> introducing it to base MPLS, but instead solve this for MPLS and use it
> everywhere.
> 
> >> Cc: Eric Gray <[email-masked]>; Loa Andersson <[email-masked]>;
> >> Greg Mirsky <[email-masked]>; mpls <[email-masked]>; Rakesh
> >> Gandhi
> >> Also what happens if the MPLS payload is a PW or Detnet or something
> >> else defined to be immediately below the bottom label?
> >>
> >> Stewart
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
> NEt6yMaO-gk!SuMXa-Es-
> oW3RUCmQB2RzdQQenskdsvnP0fvhz9Aw0vFdmyWXBNS9CIxztAHExY$

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 18 Jan 2021 09:36:05 -0800

+1

Regards,
Jeff

> On Jan 18, 2021, at 08:47, John E Drake <jdrake=[email-masked]> wrote:
> 
> I agree with Stewart.
> 
> Yours Irrespectively,
> 
> John
> 
>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 18 Jan 2021 21:36:08 +0000

Hi Stewart,

Thanks for the suggestion. Agree with making this generic to MPLS and not specific to SR-MPLS.

Thanks,
Rakesh

From: Stewart Bryant <[email-masked]>
Date: Monday, January 18, 2021 at 10:39 AM
To: Mach Chen <[email-masked]>
Cc: Stewart Bryant <[email-masked]>, Eric Gray <[email-masked]>, loa Andersson <[email-masked]>, Greg Mirsky <[email-masked]>, mpls <[email-masked]>, Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]>, mpls-chairs <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
Hi Mach

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Tue, 19 Jan 2021 10:58:07 +0800

Rskesh,

I agree making it mpls generic. Actually looking at it is pretty close to that, with minor edits it is possible to read the references to SR as examples. 

We should move this discussion to the working group mailing list. 

Rakesh, 
Can send a mail to the list, outlining what we agreed to and ask for comments?

/Loa

Sent from my iPhone

> On 19 Jan 2021, at 05:52, Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]> wrote:
> 
> 
> Hi Stewart,
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 19 Jan 2021 11:00:37 +0800

Oooopps!

the list was already copied, well fine. Please comment!

/Loa

Sent from my iPhone

> On 19 Jan 2021, at 10:58, Loa Andersson <[email-masked]> wrote:
> 
> Rskesh,
>