Skip to main content

Last Call Review of draft-ietf-mpls-sfl-control-04
review-ietf-mpls-sfl-control-04-tsvart-lc-scharf-2023-11-24-00

Request Review of draft-ietf-mpls-sfl-control
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2023-11-27
Requested 2023-11-13
Authors Stewart Bryant , George Swallow , Siva Sivabalan
I-D last updated 2023-11-24
Completed reviews Rtgdir Last Call review of -03 by Stig Venaas (diff)
Opsdir Last Call review of -04 by Joel Jaeggli
Secdir Last Call review of -04 by Charlie Kaufman
Genart Last Call review of -04 by Ines Robles
Tsvart Last Call review of -04 by Michael Scharf
Assignment Reviewer Michael Scharf
State Completed
Request Last Call review on draft-ietf-mpls-sfl-control by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/DKFfC0qjJ4mAwpAj-nHilhUmIWM
Reviewed revision 04
Result On the Right Track
Completed 2023-11-24
review-ietf-mpls-sfl-control-04-tsvart-lc-scharf-2023-11-24-00
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.

The document defines a basic control protocol over a Generalized Associated
Channel (G-ACh) in an MPLS network. The purpose of the simple protocol is to
configure certain state on an MPLS router.

*Major issues*

The document does not discuss many typical message transport issues, including
amongst others:

- What happens if a message (request or reply) gets lost, e.g., due to bit
errors, congestion, receiver failure, etc.

- Whether a message can get too large to get transmitted, e.g., because it
exceeds the MTU

- What happens if a router gets overloaded, e.g., the router control plane
cannot handle requests

- (more could be added)

Even in a well-managed MPLS network errors and failures can probably occur.

Yet, it is impossible to determine whether the proposed protocol design is
indeed robust in such cases, given the lack of specification and also the lack
of normative guidance regarding many details.

As many design choices are left to the implementer, it is also difficult to
understand if different implementations would indeed correctly interop, most
notably in the reaction to failure cases. It is not clear whether there has any
experimentation with this protocol.

*Minor issues*

- There is probably an unstated assumption that "Session Identifier" values
must be different in subsequent messages.

- To prevent congestion or receiver overload, the statement "A Querier MUST
wait a configured time (suggested wait of 60 seconds) before re-attempting
negotiation for a resource." is not sufficient. A robust protocol design would
typically required normative statements mandating a minimum timeout value and
an exponential timer backoff.

*Nits*

- In Section 1 apparently a full stop is missing after "This protocol is
designed for use in a well-managed MPLS network"

- In Section 1: "prodocols"

- In the IANA section: "0x11 SFL-Unable" lacks the reference "This document"