[Tsv-art] Tsvart last call review of draft-ietf-mpls-rmr-12

Colin Perkins via Datatracker <noreply@ietf.org> Tue, 05 November 2019 23:30 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
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)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Colin Perkins via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: draft-ietf-mpls-rmr.all@ietf.org, last-call@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.108.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Colin Perkins <csp@csperkins.org>
Message-ID: <157299662261.4537.207640958778372329@ietfa.amsl.com>
Date: Tue, 05 Nov 2019 15:30:22 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/CWQrkwWnrKH4P0l5zyU0JNXZJuk>
Subject: [Tsv-art] Tsvart last call review of draft-ietf-mpls-rmr-12
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.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
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.

- 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?