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

[Weiqiang Cheng <[e-mail]>]

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:[e-mail]] 
发送时间: 2020年12月9日 22:55
收件人: [e-mail]; [e-mail]; Mach Chen
抄送: '[e-mail]'
主题: 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.

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.

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

 

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

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

 

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.

<Weiqiang> OK, will make the alignment.

 

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

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

 

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)?

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

 

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

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

 

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.

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

 

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.

<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