[Gen-art] GenART review of draft-ietf-pwe3-redundancy-06

Martin Thomson <martin.thomson@gmail.com> Fri, 16 March 2012 03:06 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29E121E803C for <gen-art@ietfa.amsl.com>; Thu, 15 Mar 2012 20:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.367
X-Spam-Level:
X-Spam-Status: No, score=-4.367 tagged_above=-999 required=5 tests=[AWL=-1.368, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDMiF2G6jAKK for <gen-art@ietfa.amsl.com>; Thu, 15 Mar 2012 20:06:42 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6F2C21E8020 for <gen-art@ietf.org>; Thu, 15 Mar 2012 20:06:41 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so3052657bku.31 for <gen-art@ietf.org>; Thu, 15 Mar 2012 20:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Fq+hlZtq8vXtTlYqQb/3sxlEI6J0FjALnMxpAmSe/aM=; b=xQDMVCW7Jn/pv5aFFLFyaLbgJvuIiLjsiQGDUoc2/SHWN1uoCBU4NMDcS7OWk+UCYc IahwWc1O5qqhOyboicsMilDjanLh87V8L9UDWfaGJu6Pr89RX/EfnN7nimVy7ArGWiEt 5Z/tj97nkgRIEX9tz2x5HmeigPvjLY1YwMlitKc+MxsVzH0Ep10H1UCraSao8eAPzmkw 8JLPIP8u8s3EgwmyoiPqfgUNWG0WH316q4niphcRaWpirym5mYDeEZtQzim2/MvbPP/r HXqSEgvSMBM/9q5Ubw61bQ9Z5S2PQ0L/TR9Kv1BTkXXaI9IfhGPf3rHjphS640vSriJD i6rQ==
MIME-Version: 1.0
Received: by 10.204.156.141 with SMTP id x13mr328349bkw.50.1331867200816; Thu, 15 Mar 2012 20:06:40 -0700 (PDT)
Received: by 10.204.121.208 with HTTP; Thu, 15 Mar 2012 20:06:40 -0700 (PDT)
Date: Thu, 15 Mar 2012 20:06:40 -0700
Message-ID: <CABkgnnWefLUiSfxyEZpMck9moFeu7wHWk9-yAgHKDukLAt7EiQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: draft-ietf-pwe3-redundancy.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
Cc: gen-art@ietf.org
Subject: [Gen-art] GenART review of draft-ietf-pwe3-redundancy-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2012 03:06:42 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-pwe3-redundancy-06
Reviewer: Martin Thomson
Review Date: 2012-03-15
IETF LC End Date: 2012-03-21
IESG Telechat date: (if known)

Summary: The draft has some minor issues.

Major issues: none

Minor issues:

3.2.2 states: "The mechanisms for achieving this selection are outside
the scope of this document."

The example then describes the _conditions_ under which the selection
is made.  So the statement doesn't quite make sense.  It's reasonable
to presume that a standard doesn't prescribe the internal behaviour of
a PE where interoperability is no concern.  Even though this is just
an example, it makes a very specific presumption about the behaviour
of the PE in reaction to an event.  I can't imagine any other reaction
in this case, so I'm left wondering: what exactly is out of scope for
this?  Communication of the event between PE1 and PE2?

Section 4.1: "Non-revertive behavior MUST be supported, while
revertive behavior is OPTIONAL."

The reason for this requirement is non-obvious (at least to me).  Some
justification for it seems appropriate.

Section 4.1:    "Protection switchover can be triggered by the operator [...]"

Again, justification would be nice.  This actually smells more like a
product specification that requirement for interoperability.  If the
requirement is, as I suspect, that switchovers triggered by manual
intervention can be marked as such in the protocol _so that they can
be treated with lower priority_, then that is definitely
understandable.

Section 4.2:    "[...] MUST support the configuration of revertive or
non-revertive protection switching modes."

If revertive switching is optional, then this requirement makes not
sense for (T-)PEs that don't implement it.

Nits:
The figures are somewhat difficult to read overall.  It's unclear what
significance is attached to the dots in many of the diagrams, since
they aren't always consistent (see Figure 3).
Figure 5 is especially difficult to read.  Another instance is the
choice of '.' or '|' in Figure 4, which could have some significance,
but probably doesn't because the usage is quite inconsistent.  Having
labels for lines/tunnels impinge on boxes is difficult to interpret.
Reducing the noise in the diagrams would help.  The text is adequate
to make up the shortfall.  (Figure 7 is perfectly clear.)

Labeling of PEs in 3.2.2 makes it hard to follow because PE2 is
attached to CE2.  I'd suggest renames such that you have {CE1, PE1a,
PE1b} and likewise.

The first requirement in 4.1 is missing a couple of spaces (after the
comma, in "besupported").

4.2 has an empty bullet.

Not expanded on first use: PSN, LDP