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

[Italo Busi <[e-mail]>]

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