Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-mpls-rfc6374-sfl-?? Reviewer: Elwyn Davies Review Date: 2021-02-02 IETF LC End Date: 2021-01-26 IESG Telechat date: Not scheduled for a telechat Summary: Not Ready. Apologies that this review is rather late, but I found this document extremely hard to work with. There appear to be a number of areas where the work is rather too much in progress rather than ready for publication as an RFC. I also found it very difficult, not just as someone who is not at all familiar with this area of work, but at a basic technical level to work out what the protocol was going to be able to achieve and whether a LSR would garner the information it appeared to need to deliver what was clamed. Part of this appeared to be due to multiple names being used for the same thing and being used with other than their natural meaning particulaly in sections 7.1 and 7,2. Major Issues: s7, What is being standardized?: > A number of methods are described. The expectation is that the MPLS > WG possibly with the assistance of the IPPM WG will select one or > maybe more than one of these methods for standardization. > I find this statement very confusing. This document is intended for standards track, so if it goes ahead as is, the three methods are standardised and implementors would be expected to provide support for all of them unless there are to be words to indicate that not all need to be supported. Is this the intention? Or is it that this document should only support the methods chosen by the MPLS working group? In the latter case, this document is definitely not ready for standardization; I assume the unused method(s) would be removed in this case. Otherwise the second sentence is speculative and should be removed. s7, Title, purpose and general method: Note that I have very limited knowledge of this area of performance measurement so there may be misunderstandings here. However, given that caveat, I did not find the document very helpful in enlightening me and a considerable amount of background reading was needed to try and determine what was going on. Firstly, I assume that this section covers the 'additional techniques' mentioned in the Abstract and described as 'more sophisticated measurements' in s1. [Perhaps common phraseology would be desirable between the two cases.] I suggest a sentence to make this clear would be desirable. Secondly, AFAICS these techniques are basically about measuring and communicating delay jitter in various ways. It might be helpful to link what is being offered here with RFC 5481 and the discussion of delay variation measurement in RFC 6374. Section 7.1 is, as I understand it, covering IPDV measurement using (in general) normal service packets rather than just specialised RFC 6374 packets and working primarily on one LSR. I assume that the technique in s7.2 is primarily a means for reporting measurements derived from s7.1 and/or s7.4, but given that actual delays are mentioned rather than inter-packet gaps, the s7.1: After the first sentence, the first paragraph talks about delay. Since the receiving LSR has no knowledge of the transmission time of each individual packet, it is not possible for the LSR to calculate actual delays without additional information - I take it that the packets are not intended to be RFC 6374 Delay Measurement Packets as these would require corresponding responses which would contravene the query interval setting and there does not appear to be a way for the LSR doing the measurements to be told the inter-packet transmission interval. Should this be written in terms of inter-packet gaps rather than delays throughout? Further, The first paragraph describes two methods of operation without saying which one should be standardised or AFAICS providing a selection flag to allow either to be used. It seems to me that an outline of how this facility might be used is pretty much essential. Would I be right in thinking that to measure the delay jitter between a source LSR (S) and destination LSR (D), the operator decides to send a set of packets at equally spaced intervals from S to D and decides on the interval and the number of packets. S then issues a Query setting the query interval to a time greater than that needed to send the set of packets and using the Bucket Jitter Measurement Message to set the bucket delay intervals around the sending interval according to the Operator's expectations of the network. D then sets up to measure the inter-packet delays up until the next Bucket Jitter Measurement message arrives after the elapse of the query interval when D returns the profile of inter-packet delays. Does the arrival of this second Bucket Jitter Measurement Message trigger a further set of measurements? And if so, how is the sequence ended? s9.1: This section is headed by an Editor's Note saying that the section needs review which may alter the format of the TLV. It is thus impossible to say if this section is ready. Minor Issues: s7.2: As with s7.1, there seems to be some confusion bettween delay and inter-packet gap. Nits/editorial comments: Abstract: The primary purpose of this document, as set out in s1, is to extend RFC 6374 to cover general MPLS networks rather than primarily MPLS-TP networks and in particular to add support for multi-point-to-point LSPs. I think that it would be helpful for the casual reader to make this somewhat clearer in the abstract. I suggest: OLD: This document describes a method of making RFC6374 performance measurements on flows carried over an MPLS Label Switched path. This allows loss and delay measurements to be made on multi-point to point LSPs and allows the measurement of flows within an MPLS construct using RFC6374. NEW: RFC 6374 describes methods of making loss and delay measurements on Label Switched Paths (LSPs) primarily as used in MPLS TransportProfile (MPLS-TP) networks. This document describes a method of making RFC6374 performance measurements on flows carried over general MPLS LSPs. In particular, it extends the technique to allow loss and delay measurements to be made on multi-point to point LSPs and introduces some additional techniques to allow more sophisticated measurements to be made in both MPLS-TP and general MPLS networks. ENDS s1, bullet 4: Would it be helpful to refer to RFC 7190 with respect to aggregation? s1, bullet 5: s/counter again/counter, again/ s3, last sentence: s/co-responding/corresponding/ [co-responding means responding together rather than matching. Look up co-respondent in cases of adultery in the divorce courts!] s3, last sentence: s/packet/packets/ s4, para 1: Expand TC: s/TC/Trafic Class (TC)/ s5, para 1: s/proxy data service packets Section 4./proxy data service packets (see Section 4)./ s5, para 2: s/This it is/Thus it is/ s5, para 2: s/are relatively independent/are made relatively independent/ s5, para 3: s/arises for the potential/arises from the potential/ s5, para after Figure 1: s/were/where/ s5, next to last para: s/which ever/whichever/ s6, para 1: s/measurement type/measurement types/; s/combination/combinations/ s7: I assume these are the additional facilities mentioned in the Introduction. It would be helpful to make this clear. s7.1, para after Figure 2: The acrronyms QTF, RTF, RPTF and DS should be expanded. There is no section 3.7 in RFC 6374. These items are defined in Section 3.2. s7.1: The formats of the various numerical fields are not specified. I assume they are unsigned integers. s7.1, Number of Buckets: I assume that an LSR is likely to have a limit for this value. If the query requests an unsupported amount should there be a specific error code? s7.3: s/In other that exception/In other than exceptional/ s7.4: The formats for the time fields in the and the Sum of Timestamps field are not specified. s8, first sentence: I am unable to parse 'a delay measurement interval defined by an SL of constant colour' before being introduced to RFC 8321. Even then I don't know what SL stands for - it is not used in RFC 8321 or RFC 6374. s9: Expand GAL on first use. s9.1: Expand FEC on first use. s9.1, para 2: Where is the concept of well-defined array of SFLs defined? s9.1, Specification of FEC field: 'This is encoded as per Section 3.4.1 of TBD'... Er, there doesn't seem to be a reference for TBD. s10: 'A future version of the *this document*...' Is this a sign of unfinishedness or an indication that further documents will address this issue? (apart from the 'the this'.) s13: I am not sure I can identify the relevant issue in s5. s14.2: s/request/requested/ s14.2, RFC Editor note: I presume the RFC Editor should be asked to delete two lines - the ones before and after the request. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
