Subject: [mpls] MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation

From: Italo Busi <[email-masked]>
Date: Wed, 9 Dec 2020 14:55:20 +0000

Hi all,

I have been selected as one of the  MPLS-RT reviewers of draft-cheng-mpls-inband-pm-encapsulation.

I have reviewed the latest version of the draft (draft-cheng-mpls-inband-pm-encapsulation-04).

I think that the document is coherent, it is useful (i.e., it addresses a real need for operational networks), and it is almost technically sound.

Therefore, I think that the draft is almost ready to be adopted as a WG document.

I have only one technical comment which I am not sure it is really blocking WG adoption but it may be worthwhile to confirm (or to address) before WG adoption: I am not sure the use of the TC field for supporting alternate marking method is fully compliant with RFC5462.

If the alternative option to allocate multiple Flow-ID labels is chosen, there are other pieces of text that need to be updated for consistency.

These are few other comments I have which can be addressed either before or after WG adoption.

1.       The insertion of the Flow-ID label stack entry has some impact on the ECMP behavior within the MPLS network which needs to be analyzed in the draft (see for example section 5 of the SFL framework draft).

2.       Editorial: the draft uses the term "VPN Label" while other RFCs uses the term "Application Label" It woudl be better  to align the terminology with other RFCs.

3.       Editorial: the text in the Introduction is a bit hard to read. The differences between this method and SFL are split between the second and the third paragraph while the third paragraph describes also the difference wrt in-situ OAM. The last paragraph describes what this draft defines wrt the mechanisms of RC8321 and RFC8372.

Moreover, some of the properties of this method (e.g., monitoring at intermediate points as well as flow identification at both LSP and VPN/application label) are inferred from the difference with other methods rather than explicitly defined as properties of this method.

It is proposed to re-organize the text in the Introduction with:

·       one paragraph describing the background information (RFC832 and RFC8372)

·       one or two paragraphs describing what this draft defines

·       one paragraph defining the differences wrt SFL

·       one paragraph defining the differences wrt in-situ OAM

4.       In section 1, the second part of the comparison with in-situ OAM is not fully clear to me:

                           furthermore, the former allows the network

   nodes to report the refined data (e.g. calculated performance

   metrics) associated with a specified flow, nevertheless the latter

   requests the network nodes to report the data (e.g. ingress interface

   and egress interface) associated with a specified packet.

Could you please provide more explanation (via e-mail or in the draft)?

5.       From section 2.1, I understand that the LSP label can be PHP-ed.

Is my understanding correct? It might be worthwhile being explicit about this.

6.       From section 2.1, I understand that when the Flow-ID is applied to both the LSP and VPN labels, the two values are independent from each other. For example, two packets can belong to the same VPN flow but to two different LSP flows (although this might depend on the ECMP behavior) or two packets can belong to two different VPN flows but to the same LSP flow.

Is my understanding correct? It might be worthwhile being explicit about this.

7.       From section 3, I understand that an intermediate node to lookup the Flow-ID label needs to perform some deep packet inspection beyond the label at the top of the label stack used to take forwarding decisions.

I think the draft should state this requirement more clearly.

It is also not clear how deep this inspection could be. For example, a P router should only inspect the LSP Flow-ID label (i.e., monitoring the LSP flow) or could it also inspect the VPN Flow-ID (i.e., monitoring the VPN flow)?

Moreover, is this inspection required at all the intermediate nodes or should it be configured somehow?

Adding some description about the configuration of the Flow‑ID on intermediate nodes in section 4 could help addressing this comment.

Italo

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 14 Dec 2020 11:19:12 +0800

Hi Italo,

Many thanks for your thorough review and insightful comments.

We've discussed them, please see inline our responses tagged with <Weiqiang>.

Best Regards,

Weiqiang (on behalf of co-authors)

发件人: Italo Busi [mailto:[email-masked]] 
发送时间: 2020年12月9日 22:55
收件人: [email-masked]; [email-masked]; Mach Chen
抄送: [email-masked]'
主题: MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation

Hi all,

<Weiqiang> In the latest -04 version of this draft, we updated the text relevant to TC field usage as alternate marking bits, that's due to the comments/queries we received from Tarek, for the details please refer to the fifth query and answer in archive: https://mailarchive.ietf.org/arch/msg/mpls/_zYXoymu05Yiq-2bKgStgzpqb0Q/. <https://mailarchive.ietf.org/arch/msg/mpls/_zYXoymu05Yiq-2bKgStgzpqb0Q/>  To our understanding, leveraging TC bits to identify alternate marking is along the lines of RFC 5462, especially due to the fact that RFC 8321 mentions many times that IP DSCP field can be used to identify alternate marking.

<Weiqiang> Actually the alternative option to allocate multiple Flow-ID labels is not recommended, for the reasons please refer to the fifth query and answer in archive: https://mailarchive.ietf.org/arch/msg/mpls/_zYXoymu05Yiq-2bKgStgzpqb0Q/.

<Weiqiang> Thanks for pointing that out and the good reference, we'll add text to address it.

<Weiqiang> OK, will make the alignment.

<Weiqiang> Make sense, thank you. We'll follow your suggestion to update the introduction part.

<Weiqiang> Of course, the text you quote intends to tell the different characteristics of the exported data. With alternate marking, the exported data is flow-based data for performance measurement, such as counter of a block. With In-situ OAM, the exported data is packet-based data for telemetry info collection, such as ingress interface of a packet. Is it more clear if we change the text to "furthermore, the former requests the network nodes to report the data used for performance measurement, nevertheless the latter requests the network nodes to report the data used for telemetry info collection"?

<Weiqiang> Yes, we think so. We'll add text to make it explicit.

<Weiqiang> Yes, we think so. We'll add text to make it explicit.

<Weiqiang> Yes, the answers to your questions depend on the configurations on the intermediate nodes. We'll add text to address this comment.

Thank you again, Italo, for the time and effort you took to review this document.

Italo

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 13 Dec 2020 23:13:04 -0500

Please be a little careful about relying on RFC 8321 for deciding what 
to put in a standards track RFC.  *321 is experimental, and therefore 
would have presumably been reviewed with a more lenient eye than is 
appropriate for PS.

Yours,
Joel

On 12/13/2020 10:19 PM, Weiqiang Cheng wrote:
> *发件人:*Italo Busi [mailto:[email-masked]]
> *发送时间:*2020年12月9日22:55
> *收件人:[email-masked]; 
> [email-masked]; Mach Chen
> *抄送:[email-masked]'
> *主题:*MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation
> 
> Hi all,
> 
> I have been selected as one of the  MPLS-RT reviewers of 
> draft-cheng-mpls-inband-pm-encapsulation.
> 
> I have reviewed the latest version of the draft 
> (draft-cheng-mpls-inband-pm-encapsulation-04).
> 
> I think that the document is coherent, it is useful (i.e., it addresses 
> a real need for operational networks), and it is almost technically sound.
> 
> I have only one technical comment which I am not sure it is really 
> blocking WG adoption but it may be worthwhile to confirm (or to address) 
> before WG adoption: I am not sure the use of the TC field for supporting 
> alternate marking method is fully compliant with RFC5462.
> 
> <Weiqiang> In the latest -04 version of this draft, we updated the text 
> relevant to TC field usage as alternate marking bits, that's due to the 
> comments/queries we received from Tarek, for the details please refer to 
> the fifth query and answer in archive: 
> https://mailarchive.ietf.org/arch/msg/mpls/_zYXoymu05Yiq-2bKgStgzpqb0Q/. 
> <https://mailarchive.ietf.org/arch/msg/mpls/_zYXoymu05Yiq-2bKgStgzpqb0Q/> To 
> our understanding, leveraging TC bits to identify alternate marking is 
> along the lines of RFC 5462, especially due to the fact that RFC 8321 
> mentions many times that IP DSCP field can be used to identify alternate 
> marking.
> 
> If the alternative option to allocate multiple Flow-ID labels is chosen, 
> there are other pieces of text that need to be updated for consistency.
> 
> <Weiqiang> Actually the alternative option to allocate multiple Flow-ID 
> labels is not recommended, for the reasons please refer to the fifth 
> query and answer in archive: 
> https://mailarchive.ietf.org/arch/msg/mpls/_zYXoymu05Yiq-2bKgStgzpqb0Q/ 
> <https://mailarchive.ietf.org/arch/msg/mpls/_zYXoymu05Yiq-2bKgStgzpqb0Q/>.
> 
> 1.The insertion of the Flow-ID label stack entry has some impact on the 
> ECMP behavior within the MPLS network which needs to be analyzed in the 
> draft (see for example section 5 of the SFL framework draft).
> 
> 2.Editorial: the draft uses the term "VPN Label" while other RFCs uses 
> the term "Application Label" It woudl be better  to align the 
> terminology with other RFCs.
> 
> 3.Editorial: the text in the Introduction is a bit hard to read. The 
> differences between this method and SFL are split between the second and 
> the third paragraph while the third paragraph describes also the 
> difference wrt in-situ OAM. The last paragraph describes what this draft 
> defines wrt the mechanisms of RC8321 and RFC8372.
> 
> Moreover, some of the properties of this method (e.g., monitoring at 
> intermediate points as well as flow identification at both LSP and 
> VPN/application label) are inferred from the difference with other 
> methods rather than explicitly defined as properties of this method.
> 
> ·one paragraph describing the background information (RFC832 and RFC8372)
> 
> ·one or two paragraphs describing what this draft defines
> 
> ·one paragraph defining the differences wrt SFL
> 
> ·one paragraph defining the differences wrt in-situ OAM
> 
> 4.In section 1, the second part of the comparison with in-situ OAM is 
> not fully clear to me:
> 
> <Weiqiang> Of course, the text you quote intends to tell the different 
> characteristics of the exported data. With alternate marking, the 
> exported data is flow-based data for performance measurement, such as 
> counter of a block. With In-situ OAM, the exported data is packet-based 
> data for telemetry info collection, such as ingress interface of a 
> packet. Is it more clear if we change the text to "furthermore, the 
> former requests the network nodes to report the data used for 
> performance measurement, nevertheless the latter requests the network 
> nodes to report the data used for telemetry info collection"?
> 
> 5.From section 2.1, I understand that the LSP label can be PHP-ed.
> 
> 6.From section 2.1, I understand that when the Flow-ID is applied to 
> both the LSP and VPN labels, the two values are independent from each 
> other. For example, two packets can belong to the same VPN flow but to 
> two different LSP flows (although this might depend on the ECMP 
> behavior) or two packets can belong to two different VPN flows but to 
> the same LSP flow.
> 
> 7.From section 3, I understand that an intermediate node to lookup the 
> Flow-ID label needs to perform some deep packet inspection beyond the 
> label at the top of the label stack used to take forwarding decisions.
> 
> It is also not clear how deep this inspection could be. For example, a P 
> router should only inspect the LSP Flow-ID label (i.e., monitoring the 
> LSP flow) or could it also inspect the VPN Flow-ID (i.e., monitoring the 
> VPN flow)?
> 
> Adding some description about the configuration of the Flow‑ID on 
> intermediate nodes in section 4 could help addressing this comment.
> 
> <Weiqiang> Yes, the answers to your questions depend on the 
> configurations on the intermediate nodes. We'll add text to address this 
> comment.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 14 Dec 2020 19:14:06 +0800

Hi Joel,
Thanks a lot for your comments.
Leveraging TC bits to identify alternate marking is along the lines of RFC 5462, which renames "EXP" field to "Traffic Class" field, at the same time remains the TC usage as DSCP (defined in RFC 3270) and the TC usage as ECN (defined in RFC 5129), so it is safe in the context.

Best Regards,
Weiqiang

-----邮件原件-----
发件人: Joel M. Halpern [mailto:[email-masked]] 
发送时间: 2020年12月14日 12:13
收件人: Weiqiang Cheng; 'Italo Busi'; [email-masked]; [email-masked]; 'Mach Chen'
抄送: [email-masked]
主题: Re: [mpls] MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 14 Dec 2020 08:53:36 -0500

Yes, RFC 5462 section 2.3 is a good reference for what you are doing.
My concern was that your earlier comment seemed to rely on an 
experimental RFC.  I am not objecting to the work itself.

Yours,
Joel

---

From: Italo Busi <[email-masked]>
Date: Tue, 29 Dec 2020 08:04:59 +0000

Weiqiang,

Thanks for addressing my comment. I am ok with your proposed resolution.

Italo

From: Weiqiang Cheng [mailto:[email-masked]]
Sent: lunedì 14 dicembre 2020 04:19
To: Italo Busi <[email-masked]>; [email-masked]; [email-masked]; Mach Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation

Hi Italo,

Best Regards,

发件人: Italo Busi [mailto:[email-masked]]
发送时间: 2020年12月9日 22:55
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Mach Chen
抄送: [email-masked]'
主题: MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation

Hi all,
<Weiqiang> In the latest -04 version of this draft, we updated the text relevant to TC field usage as alternate marking bits, that's due to the comments/queries we received from Tarek, for the details please refer to the fifth query and answer in archive: https://mailarchive.ietf.org/arch/msg/mpls/_zYXoymu05Yiq-2bKgStgzpqb0Q/.<https://mailarchive.ietf.org/arch/msg/mpls/_zYXoymu05Yiq-2bKgStgzpqb0Q/> To our understanding, leveraging TC bits to identify alternate marking is along the lines of RFC 5462, especially due to the fact that RFC 8321 mentions many times that IP DSCP field can be used to identify alternate marking.

•       one paragraph describing the background information (RFC832 and RFC8372)

•       one or two paragraphs describing what this draft defines

•       one paragraph defining the differences wrt SFL

•       one paragraph defining the differences wrt in-situ OAM

Italo

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Wed, 30 Dec 2020 10:48:37 +0800

Hi Italo,

Thanks a lot.

B.R.

Weiqiang Cheng

发件人: Italo Busi [mailto:[email-masked]] 
发送时间: 2020年12月29日 16:05
收件人: 'Weiqiang Cheng'; [email-masked]; [email-masked]; Mach Chen
抄送: [email-masked]
主题: RE: MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation

Weiqiang,

Italo

Hi Italo,

Best Regards,

 

Hi all,

Italo