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

Martin Thomson <martin.thomson@gmail.com> Wed, 11 April 2012 15:55 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 D5D6111E80AA for <gen-art@ietfa.amsl.com>; Wed, 11 Apr 2012 08:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.037
X-Spam-Level:
X-Spam-Status: No, score=-4.037 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, 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 TgyvsliUyM8c for <gen-art@ietfa.amsl.com>; Wed, 11 Apr 2012 08:55:24 -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 EF1A011E809C for <gen-art@ietf.org>; Wed, 11 Apr 2012 08:55:23 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so1020482bku.31 for <gen-art@ietf.org>; Wed, 11 Apr 2012 08:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bsafEqXIIdujL7H8e4iiFMbxWyQP9sVjeXj1Xvld3Rs=; b=eR+tgef4Y9DyvGpr4YoV/0q5w2l6METcpvfE3qhGk0JP8i99zbujCo2yUlSS0ANYBR zBJ2FoyKySDmqybAIU3Gj5Z82swcHrM+OhRsuiyd05YjSyLB9bDXPiVxdweZfW7xoFOX JndOTd/z1+NvYuBquTegGin8YjDf+ey/z26vS6H/byB733F3Po2IzTpIeaoUY8yPkpuK 2sT094pSzWoUWyyK9N18kVj25PdiV1Z4HaU+2r59UcERw/MeyXM+vOLYp2I/kSDu7qqt 6JcpXggyDMForY3ROsII334C6rAH4VKKamlQGbTsvIdkSeEB8hHcCI26XF7f2FXUxuAG cwFA==
MIME-Version: 1.0
Received: by 10.204.156.79 with SMTP id v15mr6193549bkw.37.1334159722926; Wed, 11 Apr 2012 08:55:22 -0700 (PDT)
Received: by 10.204.165.66 with HTTP; Wed, 11 Apr 2012 08:55:22 -0700 (PDT)
In-Reply-To: <CBAA1236.28476%matthew.bocci@alcatel-lucent.com>
References: <CABkgnnWefLUiSfxyEZpMck9moFeu7wHWk9-yAgHKDukLAt7EiQ@mail.gmail.com> <CBAA1236.28476%matthew.bocci@alcatel-lucent.com>
Date: Wed, 11 Apr 2012 08:55:22 -0700
Message-ID: <CABkgnnV8WCeQWiYY9wdVfQM8p5n=S6JxdqQ4gZgkLxg21J8RMw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "draft-ietf-pwe3-redundancy.all@tools.ietf.org" <draft-ietf-pwe3-redundancy.all@tools.ietf.org>, "gen-art@ietf.org" <gen-art@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
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: Wed, 11 Apr 2012 15:55:25 -0000

On 11 April 2012 06:44, Bocci, Matthew (Matthew)
<matthew.bocci@alcatel-lucent.com> wrote:
> MB> Yes, it's really the communication mechanisms. Those details are
> specified in the separate, standards-track,
> draft-ietf-pwe3-redundancy-bit, which does impact interoperability.
> Therefore I propose updating this sentence to clarify what is out of
> scope.
> "The mechanism for communicating the preferential forwarding status are
> outside the scope of this document. "

Since you have the reference, is the reason you don't want to
reference it that you don't want a downref?

>>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.
>
> MB> This is an operator requirement to ensure that the protocols developed
> in support of PW redundancy at least support non-revertive operation as a
> baseline. To implement a revertive behaviour, you will need to designate
> one of the Pws

So you had a choice: one mandatory, but which; or both mandatory.  The
WG chose non-revertive as the only mandatory option.  I guess I was
(obliquely) requesting that you provide motivation in the document,
rather than just in response to my mail.

>>Section 4.1:    "Protection switchover can be triggered by the operator
> MB> This requirement does have a protocol implication, both in terms of
> the state machine and the ability to coordinate the state at both PEs in
> the case
> that a manual switchover is initiated from only one PE.

The process that you describe doesn't address that requirement.  That
process ensures that operator intervention doesn't cause a failure by
ensuring that the operator is unable to disable a redundant PW by
removing the only active path.  From the protocol perspective, you
need a mechanism for signaling that a path is being administratively
disabled.

So:

Requirement: Protection switchover can be initiated by either PE.
Motivation: Operator intervention may be necessary to disable one part
of a redundant PW.

Product requirement: Operator intervention shall not be able to
disable a PW by disabling the only available part of a redundant PW.

(Excuse the sloppy terminology, it's been a while and I'm too lazy to
get this right.)

I don't have any real problem with your explanations, but it seems to
me at least that it could be made clearer.  Don't feel obligated to
change on my accord alone, but there are value in being really clear
about these requirements.

--Martin