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

[chengweiqiang <[e-mail]>]

Understood, thanks a lot. 

B. R. 
Weiqiang

 	



---原始邮件---


 发件人: Joel Halpern Direct  <[e-mail]>
 发送时间:  2020-12-14 21:53:36
 收件人:  Weiqiang Cheng  <[e-mail]>
Italo Busi <[e-mail]>
draft-cheng-mpls-inband-pm-encapsulation <[e-mail]>
Mach Chen <[e-mail]>
 抄送:  mpls <[e-mail]>
 主题: Re: [mpls] MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation

     
	


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,JoelOn 12/14/2020 6:14 AM, Weiqiang Cheng wrote:> 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:[e-mail]]> 发送时间: 2020年12月14日 12:13> 收件人: Weiqiang Cheng 'Italo Busi' [e-mail] [e-mail] 'Mach Chen'> 抄送: [e-mail]> 主题: Re: [mpls] MPLS-RT review of draft-cheng-mpls-inband-pm-encapsulation> > 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>>> > >