[Tsv-art] Tsvart last call review of draft-ietf-mpls-rmr-12
Colin Perkins via Datatracker <email@example.com> Tue, 05 November 2019 23:30 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FAC1202DD; Tue, 5 Nov 2019 15:30:22 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Colin Perkins via Datatracker <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Reply-To: Colin Perkins <firstname.lastname@example.org>
Date: Tue, 05 Nov 2019 15:30:22 -0800
Subject: [Tsv-art] Tsvart last call review of draft-ietf-mpls-rmr-12
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2019 23:30:23 -0000
Reviewer: Colin Perkins Review result: Almost Ready 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 email@example.com 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?
- [Tsv-art] Tsvart last call review of draft-ietf-m… Colin Perkins via Datatracker