Last Call Review of draft-ietf-mpls-rfc6374-sfl-08
review-ietf-mpls-rfc6374-sfl-08-tsvart-lc-kuehlewind-2021-01-25-00

Request Review of draft-ietf-mpls-rfc6374-sfl
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2021-01-26
Requested 2021-01-12
Authors Stewart Bryant, George Swallow, Mach Chen, Giuseppe Fioccola, Greg Mirsky
Draft last updated 2021-01-25
Completed reviews Rtgdir Last Call review of -08 by Andy Smith (diff)
Opsdir Last Call review of -08 by Sheng Jiang (diff)
Genart Last Call review of -08 by Elwyn Davies (diff)
Secdir Last Call review of -08 by David Mandelberg (diff)
Tsvart Last Call review of -08 by Mirja K├╝hlewind (diff)
Assignment Reviewer Mirja K├╝hlewind 
State Completed
Review review-ietf-mpls-rfc6374-sfl-08-tsvart-lc-kuehlewind-2021-01-25
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/Ay7T09RhmSmRCF_wOuc5MSouA3o
Reviewed rev. 08 (document currently at 10)
Review result On the Right Track
Review completed: 2021-01-25

Review
review-ietf-mpls-rfc6374-sfl-08-tsvart-lc-kuehlewind-2021-01-25

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

I have one high level comment from a TSV point of view regarding RFC8321 below, however, unfortunately this document is in some places editorially not easy to follow and there are multiple places in the document where the document appears to not be ready to proceed out of the working group:

E.g. section 7 contains the following text:

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

Is the plan still to select one? If not, why are these different formats needed?

Also there is this editorial note in Sec 9.1:

"Editor's Note we need to review the following in the light of further
   thoughts on the associated signaling protocol(s).  I am fairly
   confident that we need all the fields other than SFL Batch and SFL
   Index.  The Index is useful in order to map between the label and
   information associated with the FEC.  The batch is part of the
   lifetime management process."

And in this context also the purpose of section 10 is unclear to me:

"A future version of the this document will discuss the applicability
   of the various methods to pro-active and on-demand Measurement."

One procedural comment: I had to take a look at draft-ietf-mpls-sfl-framework to look up the concept of SFL which suggests to me that this document should probably be a normative reference.

Now regarding RFC8321: The marking scheme shown in section 5 seems to assume a RFC832-like marking. RFC8321 is mentioned (only) in section 8, however, the discussion there is rather unclear to me. To me it seem that RFC8321 marking is assumed and as such this should be stated clearly in the introduction, potentially with a normative reference to RFC8321.

Some nits: 
- Sec 5: "acting as proxy data service packets Section 4" -> ... as described in Section 4...?
- Sec 5: "This it is proposed" -> "Thus it is proposed"
- Sec 5: "that in the time interval being analyzed, 10 packets always flow." -> Maybe "that 10 packets are used in each flow in the time interval being analyzed" ...?
   packets always flow.