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

Stewart Bryant <stbryant@cisco.com> Thu, 05 April 2012 17:02 UTC

Return-Path: <stbryant@cisco.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 A5C6D21F86DF; Thu, 5 Apr 2012 10:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.224
X-Spam-Level:
X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 iBffbiD5jm0U; Thu, 5 Apr 2012 10:02:28 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1AC21F8648; Thu, 5 Apr 2012 10:02:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3344; q=dns/txt; s=iport; t=1333645348; x=1334854948; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rAPEzZXb4tzeoXKa08Qn+Y+j+LGaIYaHJqzFXK4VNcI=; b=VxDD1E0eCo13r6jFbdxfJvXz4s8YdbUzbaWIfON583iIrQzYqeBp39pj kXxQ7i1yxgfyjhnug/X0dIPKXy7n4AIMv3DgMdRoE8Hav6J6KZZXKb2t/ 5K/RUq1Ndzb0fx7WZj2bchxZG2e1yDOHBTykV27Rt4/ejXr37/alnI8cr I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAD7PfU+Q/khR/2dsb2JhbABFhW+zAIEHggkBAQEEEgECDhVAARALFAQCAgUWCwICCQMCAQIBRQYNAQcBAR6HbAubA4M8EIk8kmeBL44TgRgElWuBEY06gQJngmg
X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="134423395"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2012 17:02:27 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q35H2RQg023880; Thu, 5 Apr 2012 17:02:27 GMT
Received: from dhcp-bdlk10-data-vlan300-64-103-107-147.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q35H2PVe028809; Thu, 5 Apr 2012 18:02:25 +0100 (BST)
Message-ID: <4F7DD021.4070807@cisco.com>
Date: Thu, 05 Apr 2012 18:02:25 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnWefLUiSfxyEZpMck9moFeu7wHWk9-yAgHKDukLAt7EiQ@mail.gmail.com>
In-Reply-To: <CABkgnnWefLUiSfxyEZpMck9moFeu7wHWk9-yAgHKDukLAt7EiQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-pwe3-redundancy.all@tools.ietf.org, gen-art@ietf.org, pwe3 <pwe3@ietf.org>, IETF Discussion <ietf@ietf.org>
Subject: Re: [Gen-art] GenART review of draft-ietf-pwe3-redundancy-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
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: Thu, 05 Apr 2012 17:02:29 -0000

Authors

Please can you answer or address these comments

Thanks

Stewart

On 16/03/2012 03:06, Martin Thomson wrote:
> 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
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html