RFC6374 Synonymous Flow Labels
Note: This ballot was opened for revision 09 and is now closed.
Alvaro Retana No Objection
Erik Kline No Objection
[[ nits ]] [ section 5 ] * "need to analyzed" -> "need to be analyzed", I suspect * "need to considered" -> "need to be considered", perhaps [ section 7.1 ] * "need to time intervals between buckets to be programmable" -> "need the time intervals between buckets to be programmable", maybe [ section 12 ] * "request.1" -> "request."
Martin Duke No Objection
- In Section 6, I understand the intent of #5 ("The duration of a second delay (D in Figure 1 batch must be such that all packets from the packets belonging to a first delay batch (C in Figure 1)will have been received before the second delay batch completes.") But given that this is a delay measurement, how can we ensure this property? Is this better formulated as "the sender will not stop sending for D until it receives feedback for C", or something to that effect? - Sec 9.1: What does it mean that SPL Index is an "optional convenience"? Is the sender required to set it properly, but the receiver is free to ignore it if unneeded? Or is this optional for the sender somehow as well?
Murray Kucherawy No Objection
Please expand "PW" and "OAM" on first use (Section 1).
Robert Wilton No Objection
Hi, Thanks for this document. One minor nit: The document doesn't formally define the meaning of the reserved field in 7.2.1 and 7.4. Regards, Rob
Roman Danyliw No Objection
Thank you to David Mandelberg for the SECDIR review. * Section 12. The cautions described in RFC6374 seem to largely apply here too. Please note that.
Warren Kumari No Objection
Much thanks to Sheng Jiang for the OpsDir review - due to time constraints I'm relying heavily on the directorate reviews this week. Thanks!
Éric Vyncke No Objection
(Deborah Brungard; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Dropping from Discuss to No Objection based on edits staged in the editor's copy. Previous Discuss section: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% There may be a couple of internal (or external?) inconsistencies lingering, and while my confidence level of that is not as high as it often is, it's probably still worth checking. Specifics in the COMMENT, but at a high level, do we use ACH value 0x000A (what's shown in Section 9) or the TBD IANA-allocated values; we seem to refer to RFC 6374 as providing some things that I can't find in it; and the IANA considerations registration request includes a "TLV follows" column that does not appear to be present in the registry (and does not appear to match the described behavior in the rest of the document). Perhaps this (the current registry state) is the result of RFC 7026's actions, but I'm not entirely sure. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Previous Comment section: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% A bit more introduction about how the term "delay" is used as effectively synonymous with "inter-packet gap" (for purposes of the mechanisms presented in this document) would be appreciated. Abstract, Introduction (editorial) the phrases "general MPLS LSPs" and "general MPLS case", while intended to contrast against RFC 6374's restriction to just MPLS-TP, looks rather similar to "generalized MPLS" and could be a bit confusing. I'd suggest a phrasing like "the generic case of MPLS LSPs, not limited to MPLS-TP". Section 5 I'd suggest a legend that A/B are colors for loss measurement and C/D are delay groups, and what is depicted is a time series of (the marking of) packets transmitted. measurement types would be identical. Thus, it is proposed that the two measurements are made relatively independent from each other. How does this "proposed" relate to the simplifying rules in Section 6 that put some fairly strong dependencies on how delay measurements relate to loss measurements? Section 7.1 The packet format of an RFC6374 Time Bucket Jitter Measurement Message is shown below: It seems a little misleading to have "RFC6374" in the name here without some classifier such as "framework" or "style", since the actual structure does not appear in RFC 6374. (Similarly for the other message formats.) Section 7.2.1 The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, Session Identifier, and DS Fields are as defined in section 3.7 of RFC6374. The remaining fields are as follows: I don't see a Section 3.7 in RFC 6374. This does, however, look like a lot like Section 3.3 thereof. Section 7.4 In this approach the packet is time-stamped at arrival and the Responder returns the sum of the time-stamps and the number of times- tamps. From this the analytics engine can determine the mean delay. An alternative model is that the Responder returns the time stamp of the first and last packet and the number of packets. This method has the advantage of allowing the average delay to be determined at a number of points along the packet path and allowing the components of the delay to be characterized. This prose suggests that an implementation or deployment might choose only one or the other of the "alternative model"s, but the packet layout and accompanying field descriptions suggest that all fields are to be populated, always. Some clarity on whether it is permissible to select only one of the alternatives would be welcome. The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, Session Identifier, and DS Fields are as defined in section 3.7 of RFC6374. The remaining fields are as follows: (There is still no Section 3.7 in RFC 6374.) Section 8 (editorial) The purpose of this section is somewhat unclear. It seems that the current text can (very roughly) be summarized as: "up until now, we assume we measure every packet in a colored interval. RFC 8321 did some other stuff; [details elided]. The RFC 8321 approach is not impacted by ECMP effects." Nowhere does it seem to say that the RFC 8321 approach is directly applicable to the RFC 6374-style packets defined in this document, or some other reason why these facts are noteworthy in the context of this document. Section 9 Why do we only depict the use of ACH 0x000A (MPLS Direct Loss Measurement) when we also perform delay measurement (which might use ACH 0x000C) and also seem to be allocating three additional codepoints that would go in this range? Should the figure still refer to an "RFC6374 Fixed Header" even though we admit variable-length headers for some measurements? (Also, it's a bit surprising to use that terminology when RFC 6374 itself does not.) The RFC6374 measurement message consists of the three components, the RFC6374 fixed header as specified in [RFC6374] carried over the ACH channel type specified the type of measurement being made (currently: loss, delay or loss and delay) as specified in RFC6374. It doesn't quite seem that "as specified in RFC 6374" applies, since (IIUC) the "fixed header" is referring to the message formats from Sections 7.1, 7.2.1, and 7.4 of this document. Two optional TLVs MAY also be carried if needed. The first is the SFL TLV specified in Section 9.1. This is used to provide the implementation with a reminder of the SFL that was used to carry the RFC6374 message. This is needed because a number of MPLS implementations do not provide the MPLS label stack to the MPLS OAM handler. This TLV is required if RFC6374 messages are sent over UDP [RFC7876]. This TLV MUST be included unless, by some method outside the scope of this document, it is known that this information is not needed by the RFC6374 Responder. Is any entity tasked with ensuring consistency between the actual label stack and the value in this TLV? otherwise MUST be carried. The return address TLV is defined in RFC6378 and the optional UDP Return Object is defined in [RFC7876]. The Return Address TLV is specified in RFC 6374, not RFC 6378. Section 9.1 The required RFC6374 SFL TLV is shown in Figure 6. This contains the (nit) per the previous section, this TLV is only mostly required. SPL Index The index into the list of SFLs that were assigned against the FEC that corresponds to the SFL. Multiple SFLs can be assigned to a FEC each with different actions. This index is an optional convenience for use in mapping between the TLV and the associated data structures in the LSRs. Is there any entity tasked with ensuring consistency between the index, the SFL, and the batch? Section 12 While I agree that there's not much new in this document, incorporating by reference the considerations from (e.g.) 6374 and 8372, if not more, seems in order. If I understand correctly those would also pull in the documentation of the generic privacy considerations with using user data for monitoring. One thing that might be new in this document is the potential for data skew between the label stack and the SFL TLV, so that depending on one's implementation the reported results would be different. (Similarly for batch/index/SFL relationships within the SFL TLV.) Section 13.1 As per the IANA considerations in [RFC5586], IANA is requested to allocate the following codeponts in the "MPLS Generalized Associated Channel (G-ACh) Type" registry, in the "Generic Associated Channel (G-ACh) Parameters" name space: The only thing I see at https://www.iana.org/assignments/g-ach-parameters/g-ach-parameters.xhtml that seems to match this description is written there as "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)". I also don't see any "TLV follows" columns on that page, and don't understand why "no" is listed for these, since Section 9 is clear that the SFL TLV is mostly mandatory. Section 16 If we are deferring to draft-bryant-mpls-sfl-control for the contents of some protocol message fields, I can't see how it's anything other than a normative reference. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection