[mpls] Tsvart last call review of draft-ietf-mpls-sfl-control-04

[Michael Scharf via Datatracker <[e-mail]>]

Reviewer: Michael Scharf
Review result: On the Right Track

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
[e-mail] 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"