RFC6374 Synonymous Flow Labels
draft-ietf-mpls-rfc6374-sfl-10

[[ 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."

Please expand "PW" and "OAM" on first use (Section 1).

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.

Much thanks to Sheng Jiang for the OpsDir review - due to time constraints I'm relying heavily on the directorate reviews this week.

Thanks!

draft-ietf-mpls-sfl-control (I-D.bryant-mpls-sfl-control) should be a Normative reference as one of the fields in the SF TLV depends on it.


[nits] 

s/subset if/subset of

s/to analyzed/to be analyzed

s/to considered/to be considered

s/request.1/request.

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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

- 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?

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