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

Kireeti Kompella <> Wed, 16 September 2020 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7593F3A08AA; Wed, 16 Sep 2020 07:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AkeLEZ_Zaeax; Wed, 16 Sep 2020 07:52:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75C373A08C7; Wed, 16 Sep 2020 07:52:25 -0700 (PDT)
Received: by with SMTP id b6so8556387iof.6; Wed, 16 Sep 2020 07:52:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EAiOocp+Sr/HZg8lw7WxSlzSIDeAVUDVHMV6E/sOPbo=; b=gnkjAkNMnsrFm/j8aSA19COHZaac5D9VtmmhL9a0LVArJqYOcee37RzvwzeZR/CcaL Bt4yj4LJYgU7df2jOikTqyq9a8pPlf6DpQ7owIOMHt99DUlLHc9hCcIERfgjJDRUxFub u1ttRRc43Gm1O6QCie6b1dAWjoxWwmC+ChqYe7/nfSFvV1oQKCdyXlVanbzBO1o302sF Zd3c9gmAb2jnZ9n2+JTjUY4MPQ3ztOn2+k2s6+AdhSXwN33Xgwld45B3H/xBq7O10zJE 6aGMwO5pcIcZB7frhJC6lEgwnPqEKtgiKwm60IyyESzvGQTCuWMBDkiZwRWvzFawk0XG ecpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EAiOocp+Sr/HZg8lw7WxSlzSIDeAVUDVHMV6E/sOPbo=; b=k+RFfJczagQ5xYCOVTefnNqN7ZD9dFowrq24iCNgA2W3CoZiEgjcUj2RaHjFzt//Bx cpqpsnFpTxhvmRRAqgocY3YM0yNUCRHxGZSBIB8Deqa660s2B9joapP5Z4WiAJmKYiNt 9IoxsyWDUptvHlRIuup1uK4h12eayc0HHyQ6oI+17fngrCguNwMaqvNNgu+diXY9eakM IrmCckgpMjMeM58bPjkEPGvN1lyX6R8ibtsAjwqwSYNiyDkajsciVBKE43EsglIx4dhd oNU2qGIJAKBwZVfTqJA9vvsixDfYPVJhU9WHW3pUNUjel7BuTPxgmiVyBxgHrXCUYu/B g/+A==
X-Gm-Message-State: AOAM533vaUUjXYZjaXMeyR+Cv6Rxnq2UATm5j4pZPZp9Ox8CklRfDOXA HMLYJq6tZGgWjmXEG4LJnLcX3c9/8Z5F8dqtcn3JAEKFEiI=
X-Google-Smtp-Source: ABdhPJxJwmutqh4xYva6NedKf7FgEJU5g8M5jVAUPkTSkVC6UqwC1dRej7UkbG/y/VZiFEvkUE9dvJhKQg/rNuNyF/8=
X-Received: by 2002:a05:6638:220c:: with SMTP id l12mr21953731jas.139.1600267944673; Wed, 16 Sep 2020 07:52:24 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Kireeti Kompella <>
Date: Wed, 16 Sep 2020 07:52:13 -0700
Message-ID: <>
To: Colin Perkins <>
Content-Type: multipart/alternative; boundary="0000000000006346fa05af6f6a0e"
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-mpls-rmr-12
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Sep 2020 14:52:29 -0000

Hi Colin,

Sorry for the very belated response!

Thank you for your review.  All of your comments have been addressed in the
-13 update; section 1.2 has a summary of the changes, marked with [TAR] for
the Transport Area Review.  Section 4.2 has updated text on timers;
unfortunately, there are two typos here: one, this change was made in
response to TAR, not SAD; two, the actual change was duplicated.  Section 5
defers the value of the OAM timer to the OAM protocol being used.

The nits in section 1 & 1.1 have also been fixed.

Hopefully, all your concerns have been addressed.


On Tue, Nov 5, 2019 at 3:30 PM Colin Perkins via Datatracker <> wrote:

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