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

["Joel M. Halpern" <[e-mail]>]

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:
> 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/ 
> <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
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>