Subject: [mpls] I-D Action: draft-gandhi-mpls-ioam-sr-05.txt

From: [email-masked]
Date: Sat, 09 Jan 2021 07:47:47 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching WG of the IETF.

        Title           : MPLS Data Plane Encapsulation for In-situ OAM Data
        Authors         : Rakesh Gandhi
                          Zafar Ali
                          Clarence Filsfils
                          Frank Brockners
                          Bin Wen
                          Voitek Kozak
	Filename        : draft-gandhi-mpls-ioam-sr-05.txt
	Pages           : 14
	Date            : 2021-01-09

Abstract:
   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in the data packet while the
   packet traverses a path between two nodes in the network.  This
   document defines how IOAM data fields are transported with MPLS data
   plane encapsulation using new Generic Associated Channel (G-ACh),
   including Segment Routing (SR) with MPLS data plane (SR-MPLS).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-gandhi-mpls-ioam-sr/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-gandhi-mpls-ioam-sr-05
https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-gandhi-mpls-ioam-sr-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Tue, 12 Jan 2021 09:49:09 +0800 (CST)

Hi authors,

While looking through the updated -05 version of this draft, a question emerged in my mind, with the separated Edge-to-Edge IOAM Indicator Label and Hop-by-Hop IOAM Indicator Label, how can the network operator achieve both the Edge-to-Edge IOAM and Hop-by-Hop IOAM simultaneously?
I think there are two ways to achieve that, one way is to define the third IOAM Indicator Label which indicates the existence of both Edge-to-Edge IOAM and Hop-by-Hop IOAM, another way is to merge the current two IOAM Indicator Labels and let the IOAM Option-Type to tell the difference between Edge-to-Edge IOAM and Hop-by-Hop IOAM.

Best Regards,
Xiao Min

原始邮件

发件人：[email-masked]
收件人：[email-masked] ;
抄送人：[email-masked];
日 期 ：2021年01月09日 23:49
主 题 ：[mpls] I-D Action: draft-gandhi-mpls-ioam-sr-05.txt

        Title           : MPLS Data Plane Encapsulation for In-situ OAM Dataloo
        Authors         : Rakesh Gandhi
                          Zafar Ali
                          Clarence Filsfils
                          Frank Brockners
                          Bin Wen
                          Voitek Kozak
    Filename        : draft-gandhi-mpls-ioam-sr-05.txt
    Pages           : 14
    Date            : 2021-01-09
 
Abstract:

 

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 Jan 2021 14:24:20 +0000

There are three problems, how you encode the action and where you place the metadata, and how you accommodate anything else after BoS.

This is getting very messy and we need to solve this holistically or we will damage the future of the MPLS protocol.

The best place to indicate HxH is at ToS since this is looked at by every hop with minimum effort.

This could be via a FEC or an SPL. However I do not like the SPL approach because you probably need the EL to neutralise ECMP and that is four labels in the stack  before you even get to specify the destination. That is as many labels as some LSRs can cope with. You could I suppose have an iOAM SPL that specifies the ECMP behaviour but we are loosing our generality if we go down that route.

The best place to indicate E2E is at BoS since this is where you handle the E2E iOAM. That can be an ordinary label, and since you have to advertise E2E iOAM capability it is not much more to specify which label you expect to see BoS to indicate its presence. 

Now you have two choices to advertise both, - the ToS stuff which you do not PHP + the BoS, or one of two different BoS labels. The use of two different BoS labels is far less problematic since that is only 2 out of million available labels and you need the label in place to indicate that the packet carries E2E iOAM and not just plain IP … except that it may not carry plain IP...

Now here is what worries me.

What if the LSP is carrying a PW, or is DetNet? What if it is a MS-PW? In all these cases there is a CW immediately after BoS. Then there is the universal fragmentation idea that is floating about that also wants to follow BoS.

How do we fit in 2, possibly 3 or 4 sets of descriptor data after the BoS. This has the possibility to get very messy very quickly.

So we need to go up a level and consider how we generalise this, because iOAM needs to live with the rest of the MPLS ecosystem, and will not be the only candidate for BoS meta data. That is not to say that I have anything I want to put there that I am being quiet about, instead it is to point out that once the first genie is out of the bottle a whole bunch of their friends will soon follow behind. So we have to solve this elegantly such that we can deal with the MPLS extensions we have not yet thought of and not be tempted to just hack something in that works for the immediate case in hand.

- Stewart

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 15 Jan 2021 14:56:14 +0000

Thanks Xiao Min for your review.

Section 5.1 includes this case for the indicator.

“If both edge and transit nodes need to process IOAM data then HbH IOAM Indicator Label is used.”

In any case, IOAM data field(s) are updated according to the type of the IOAM data field(s).

Thanks,
Rakesh

From: mpls <[email-masked]>
Date: Monday, January 11, 2021 at 8:49 PM
To: [email-masked] <[email-masked]>
Subject: [mpls] Comment on draft-gandhi-mpls-ioam-sr-05

Hi authors,

Best Regards,
Xiao Min
原始邮件

Abstract:

---

From: <[email-masked]>
Date: Sat, 16 Jan 2021 11:00:51 +0800 (CST)

Hi Rakesh,

Thank you for the reply.
To me the sentence you quoted is not clear enough, the defined IOAM Tracing Option data fields are not only processed by the transit nodes, but also need to be processed by both the edge and transit nodes.
Furthermore, in Section 4.1 it says "

The E2E IOAM Indicator Label is used to indicate the presence of the
 E2E IOAM data field in the MPLS header as shown in Figure 2
" 
and in Section 5.1 it says "

The HbH IOAM Indicator Label is used to indicate the presence of the
 HbH IOAM data field in the MPLS header as shown in Figure 3
"
then the natural deduction from the above two sentences is that both the E2E IOAM Indicator Label and the HbH IOAM Indicator label would be used to indicate the presence of both the E2E IOAM data field and the HbH IOAM data field.

Best Regards,
Xiao Min

原始邮件

发件人：RakeshGandhi(rgandhi)
收件人：肖敏10093570;[email-masked];
日 期 ：2021年01月15日 22:58
主 题 ：Re: [mpls] Comment on draft-gandhi-mpls-ioam-sr-05

 

Section 5.1 includes this case for the indicator. “If both edge and transit nodes need to process IOAM data then HbH IOAM Indicator Label is used.” 

 

Thanks,

Rakesh

 

Hi authors,

 Best Regards,
 Xiao Min

原始邮件

抄送人：[email-masked];

日 期 ：2021年01月09日 23:49

 
 
 Abstract:

---

From: Loa Andersson <[email-masked]>
Date: Sun, 17 Jan 2021 13:04:03 +0800

Xiao,

imline please.

On 12/01/2021 09:49, [email-masked] wrote:
> Hi authors,
> 
> While looking through the updated -05 version of this draft, a question 
> emerged in my mind, with the separated Edge-to-Edge IOAM Indicator Label 
> and Hop-by-Hop IOAM Indicator Label,

FWIW my take here is that the Edge-to-Edge IOAM only is processed on the 
edge nodes and that Hop-by-Hop IOAM is processed by all nodes on along 
the LSP, including the edge node.

how can the network operator
> achieve both the Edge-to-Edge IOAM and Hop-by-Hop IOAM simultaneously?

If I understand this correctly that is what is done by Hop-by-Hop IOAM.

> I think there are two ways to achieve that, one way is to define the 
> third IOAM Indicator Label which indicates the existence of both 
> Edge-to-Edge IOAM and Hop-by-Hop IOAM, 

I don't see that as necessary, isn't that what the Hop-by-Hop IOAM 
indicator does.

another way is to merge the
> current two IOAM Indicator Labels and let the IOAM Option-Type to tell 
> the difference between Edge-to-Edge IOAM and Hop-by-Hop IOAM.

Does that mean that even if you are only Edge-to-Edge IOAM  you need to 
inspect the IOAM Option-Type on every node for evey packet?

My 2 c's, but I'm willing to be corrected.

/Loa
> 
> Best Regards,
> Xiao Min
> 
> 原始邮件
> *发件人：[email-masked]
> *收件人：[email-masked] ;
> *抄送人：[email-masked];
> *日 期 ：*2021年01月09日 23:49
> *主 题 ：**[mpls] I-D Action: draft-gandhi-mpls-ioam-sr-05.txt*
> 

-- 

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

---

From: <[email-masked]>
Date: Mon, 18 Jan 2021 10:00:16 +0800 (CST)

Hi Loa,

Thank you for your comments.
Please see inline my responses with <XM>.

Best Regards,
Xiao Min

原始邮件

发件人：LoaAndersson
日 期 ：2021年01月17日 13:04

Xiao,
 
imline please.

<XM> I absolutely agree.

If I understand this correctly that is what is done by Hop-by-Hop IOAM.
<XM> Per IOAM itself, the Edge-to-Edge IOAM and Hop-by-Hop IOAM are independent of each other, they use different IOAM Option-Type. Per MPLS indicator label, I agree with you that Hop-by-Hop IOAM indicator label can be reused here, but IMHO the current text in this draft is not clear on it.

<XM> See above.

Does that mean that even if you are only Edge-to-Edge IOAM  you need to  
inspect the IOAM Option-Type on every node for evey packet?
<XM> Yes, correct. Actually you provide the third way to reuse the Hop-by-Hop IOAM indicator label, for the network operator to achieve both the Edge-to-Edge IOAM and Hop-by-Hop IOAM simultaneously. Acc to the reply from the author, the third way you provide is preferred by the authors, then I suggest to document this way explicitly, in my view this way is not reflected in the current text clearly.

/Loa
 
--

---

From: Loa Andersson <[email-masked]>
Date: Mon, 18 Jan 2021 16:01:14 +0800

Xiao,

I have not been active in any OAM work, and not in the iOAM development, 
so I'm on a learning curve. So one more question.

Inline please

On 18/01/2021 10:00, [email-masked] wrote:
> <XM> Per IOAM itself, the Edge-to-Edge IOAM and Hop-by-Hop IOAM are 
> independent of each other, they use different IOAM Option-Type. Per MPLS 
> indicator label, I agree with you that Hop-by-Hop IOAM indicator label 
> can be reused here, but IMHO the current text in this draft is not clear 
> on it.

Let us assume that a packet arrive to an egress node with (1) with an
e-2-e iOAM indicator and another packet (2) arrive with the hop-by-hop 
indicator.

Is there a difference t0 what the egress node do to (1) and what it does 
to (2)?

/Loa

--

---

From: <[email-masked]>
Date: Mon, 18 Jan 2021 16:43:10 +0800 (CST)

Hi Loa,

Best Regards,
Xiao Min

原始邮件

发件人：LoaAndersson
收件人：肖敏10093570;
抄送人：[email-masked];
日 期 ：2021年01月18日 16:01

Xiao,
 
I have not been active in any OAM work, and not in the iOAM development,  
so I'm on a learning curve. So one more question.
<XM> It's my pleasure if I can help here.

Inline please

 
Is there a difference t0 what the egress node do to (1) and what it does  
to (2)?
<XM> As I understand it, there is no difference. Here the only function of iOAM indicator is for the egress node to know there exists IOAM header below the MPLS label stack, and how to process the IOAM data fields within the IOAM header depends on IOAM Option-Type.

/Loa
 
--

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 18 Jan 2021 09:11:58 -0500

Hi Loa, Xiao,

Thanks for your comments.

The Edge-to-Edge IOAM is processed on the edge nodes and
Hop-by-Hop IOAM is processed by all nodes along
the LSP, including the edge nodes.

We will update the text accordingly.

Thanks,

Rakesh

On Sun, Jan 17, 2021 at 9:01 PM <[email-masked]> wrote:

> *发件人：*LoaAndersson
> *收件人：*肖敏10093570;[email-masked];
> *日 期 ：*2021年01月17日 13:04
> *主 题 ：**Re: [mpls] Comment on draft-gandhi-mpls-ioam-sr-05*
> Xiao,
>
> imline please.
>
>
> indicator label, I agree with you that Hop-by-Hop IOAM indicator label can
> be reused here, but IMHO the current text in this draft is not clear on it.
>
> <XM> Yes, correct. Actually you provide the third way to reuse the Hop-by-Hop
> IOAM indicator label, for the network operator to achieve both the Edge-to-Edge IOAM and Hop-by-Hop IOAM simultaneously.
> Acc to the reply from the author, the third way you provide is preferred by
> the authors, then I suggest to document this way explicitly, in my view
> this way is not reflected in the current text clearly.
>

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 18 Jan 2021 09:15:01 -0500

Hi Loa, Xiao,

Please see reply inline with <RG>..

On Mon, Jan 18, 2021 at 3:44 AM <[email-masked]> wrote:

> *收件人：*肖敏10093570;
> *日 期 ：*2021年01月18日 16:01
> <XM> As I understand it, there is no difference. Here the only function of
> iOAM indicator is for the egress node to know there exists IOAM header
> below the MPLS label stack, and how to process the IOAM data fields within
> the IOAM header depends on IOAM Option-Type.
>

<RG> Yes, this is my understanding as well.

Thanks,
Rakesh