Last Call Review of draft-ietf-mpls-sfl-control-04
review-ietf-mpls-sfl-control-04-genart-lc-robles-2023-11-27-00

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://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-mpls-sfl-control-04
Reviewer: Ines Robles
Review Date: 2023-11-27
IETF LC End Date: 2023-11-27
IESG Telechat date: Not scheduled for a telechat

Summary:

This document describes a control protocol that runs over an associated control
header to request, withdraw, and extend the lifetime of MPLS synonymos flow
labels (SFL).

I have some minor comments/questions indicated below.

Major issues: None

Minor issues:

* In the text it is mentioned - "well-managed MPLS Network" (Section 1, Section
6). I think that this is vague because it lacks specific, measurable criteria.
Thus, to improve the clarity and precision of the document, it would be nice to
replace the term "well-managed" with more specific and quantifiable attributes.
Something like: "...This protocol is designed for use in an MPLS network that
adheres to Internet standard management practices such as .... [addReference,
e.g. RFC6427?]..."

* Should this draft describe how this control protocol might interact with or
support various SFL Actions? (for context and understanding the broader
application of SFLs in a network.)

* Should this draft specify topics related to the performance impact of the
protocol, including how it handles high volumes of SFL requests and scalability
in large-scale networks?

* Section 3.1 - error codes: While the draft mentions error codes, Should this
draft specify comprehensive error handling at various stages of the SFL
request, management process or operational inconsistencies?, What do you think?

* Section 3.2.4: More precise definitions or examples of what constitutes
"significantly" would be helpful.

* Section 3.2.4: Should this draft explain how these time margins might impact
network performance, especially in high-density or high-traffic scenarios?

* Section 3.2.4: Should this draft explain or reference how to manage potential
inaccuracies in timer synchronization across the network?

* Section 6: Should this draft reference RFC 5920?

Nits/editorial comments:

* Section 3. Related with the terminology, it would be nice to add RFC 5586 in
here, since it defines the Generic Associated Channel Header. I understand RFC
5586 is mentioned in IANA section, but it would be nice to include it in here
as well.

* Section 3.1: In "Flags" and "Control Code" definition it would be nice to add
a sentence such as "See below for detailed explanation", since these concepts
are expanded below in the text.

* Section 3.1:  (Allocated (A) --> (Allocated (A))

Thanks for this document,

Ines.