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?