Last Call Review of draft-ietf-mpls-rmr-12
review-ietf-mpls-rmr-12-tsvart-lc-perkins-2019-11-05-00

Request Review of draft-ietf-mpls-rmr
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-11-05
Requested 2019-10-22
Authors Kireeti Kompella, Luis Contreras
Draft last updated 2019-11-05
Completed reviews Rtgdir Early review of -09 by Susan Hares (diff)
Rtgdir Last Call review of -11 by Susan Hares (diff)
Tsvart Last Call review of -12 by Colin Perkins
Genart Last Call review of -12 by Francis Dupont
Secdir Last Call review of -12 by Derek Atkins
Opsdir Last Call review of -12 by Nagendra Kumar
Assignment Reviewer Colin Perkins
State Completed
Review review-ietf-mpls-rmr-12-tsvart-lc-perkins-2019-11-05
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/CWQrkwWnrKH4P0l5zyU0JNXZJuk
Reviewed rev. 12
Review result Almost Ready
Review completed: 2019-11-05

Review
review-ietf-mpls-rmr-12-tsvart-lc-perkins-2019-11-05

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 draft describes how MPLS can be used to configure ring topologies,
as is frequently used to provide resilience. This seems like a reasonable
thing to do - indeed I'm surprised such a specification doesn't already
exist. From a transport perspective, this looks reasonable, but I do have
some comments:

- The draft discusses resilience mechanisms, by which the ring can be
used to protect from link failures. There is, however, no discussion of
how to recover from loss of the various messages used to announce and
manage the ring network. It may be that the protocol used to convey
these messages provides appropriate reliability mechanisms and the
draft just needs to reference and clarify that. However, if not, it would
seem worth considering robustness to loss of the ring advertisement
and maintenance messages.

- Auto-discovery in Section 4 uses timers T1 and T2. It's not clear what
is the timeout value for these timers, and whether their value needs to
be statically chosen or somehow tuned based on the size of the network. 

- Similarly, Section 5 on Ring OAM specifies two timers. These have fixed
values of 3.3ms and 1s. It's not clear why these values were chosen or why
they are correct.

Nits:
- The Introduction talks about "transport networks". It's not clear what
is meant by this, and there might be an alternative term that's clearer.

- The last paragraph before Section 1.1 states: “The intent is not to
 construct rings in a mesh network,  and use those for protection”. I
can’t parse the grammar here – can you clarify?