IETF Logo Mail Archive

[RTG-DIR] RtgDir review: draft-ietf-spring-resiliency-use-cases-08

Lou Berger <lberger@labn.net> Mon, 24 April 2017 18:47 UTC

Return-Path: <lberger@labn.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A00F131938 for <rtg-dir@ietfa.amsl.com>; Mon, 24 Apr 2017 11:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71Ee8pP62v7y for <rtg-dir@ietfa.amsl.com>; Mon, 24 Apr 2017 11:47:52 -0700 (PDT)
Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD00131935 for <rtg-dir@ietf.org>; Mon, 24 Apr 2017 11:47:52 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 0BCFF1E062A for <rtg-dir@ietf.org>; Mon, 24 Apr 2017 12:47:52 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id CJno1v00C2SSUrH01Jnrks; Mon, 24 Apr 2017 12:47:51 -0600
X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=AzvcPWV-tVgA:10 a=48vgC7mUAAAA:8 a=ao-CJebsniwK8E5KxfQA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nVqSZHKvyu2BswA8Jx9ibYncmFPV8yDTw48cGtuCTXs=; b=pGKDZvETacAkHGj8KFurhDXobZ tN4vq+fIJL/v2RXfijlBJXpq0m1TYjr1cJ4RhWDOfgCz6rII4h4JWmBT1wvoRuZ1IYfJi2k2bLrFI TbhUyeZMhYhTgFJcnaxi2uw4/;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47768 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1d2j1Y-000432-2f; Mon, 24 Apr 2017 12:47:48 -0600
From: Lou Berger <lberger@labn.net>
To: rtg-ads@ietf.org
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, draft-ietf-spring-resiliency-use-cases.all@ietf.org, spring@ietf.org
Message-ID: <52f7d439-e0b3-e7c5-e0ab-c00569dad1a5@labn.net>
Date: Mon, 24 Apr 2017 12:15:23 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1d2j1Y-000432-2f
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:47768
X-Source-Auth: lberger@labn.net
X-Email-Count: 8
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/am-vSqDlpzeI5bKcNKjLwBbUooI>
Subject: [RTG-DIR] RtgDir review: draft-ietf-spring-resiliency-use-cases-08
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2017 18:47:53 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-spring-resiliency-use-cases-08
Reviewer: Lou Berger
Review Date: April 24
Intended Status: Informational

Summary:

    I have some minor comments about this document that I think would be
good, but not necessary, to be resolved before publication.

Comments:

This document is concise and clear.  I only have minor/nit level issues
that could be addressed before publication, but I don't think it
critical as the document is being published as Informational.

Major Issues:

	No major issues found.

Minor Issues:

- Section 2 mentions reversion, while sections 3 and 4 do not.
  This leaves reversion requirements open to interpretation.
  I suggest explicitly stating if reversion is a required
  option or not in sections 3 and 4 as well.

- Section 2 mentions 1:1 style path protection.  Past/other work
  on protection also allowed for / uses 1+1 style protection.  Is
  1+1 intentionally omitted? If not, I suggest allowing for it.

Nits:

>   referred to as local protection techniques or Fast Reroute
>   techniques.

References should be provided for each technique.

>    It is essential that the primary and backup path benefit from an end-
>    to-end liveness monitoring/verification.  The method and mechanisms
>    that provide such liveness check are outside the scope of this
>    document.

Given the importance of liveness monitoring, I think it would be worth
mentioned an example of such.

That's it!
Lou

v2.23.0 | Report a Bug | By Email