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

Martin Thomson <martin.thomson@gmail.com> Wed, 11 April 2012 17:23 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 061AC11E8089 for <gen-art@ietfa.amsl.com>; Wed, 11 Apr 2012 10:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.988
X-Spam-Level:
X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[AWL=-0.389, 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 u-n4Igfqu-3c for <gen-art@ietfa.amsl.com>; Wed, 11 Apr 2012 10:23:17 -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 E705E11E809B for <gen-art@ietf.org>; Wed, 11 Apr 2012 10:23:16 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so1105099bku.31 for <gen-art@ietf.org>; Wed, 11 Apr 2012 10:23:16 -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=PnY6lOoEgUr4pCRrEowXDsI4Gw98ZvNsbk8Nx7gABoc=; b=btJe+D7fDwYmnOCBqDh9ARJ3oO1TLWaokqThRzslmk5GNm0Hq+eX7Era2Ob8MJFiRD /+H30mWnz6CeuuZ1v5RBjFaCSgvEjyQNsm5iEycOLrnwHMtBAK3N/tnGmtennXLtZaTW Y1yFXsMqPAhSYWDrGAO3ldtvIlHYCQO8YaABDCgp057HlLybZFe/DCmk5pzGoUEFVQT8 6CwLGsSZkfQNtCPamAUjs0bTF1QsE6DCQrnEdEOyXsELTmUHVU5kQbpZXQbbUYtzovg4 MP2uSDCFGXaAB/e+slgtS5m3h51OfWaRdEqvter0Yp03sQjU4i+QVmComCMG/Yj5mccb grCw==
MIME-Version: 1.0
Received: by 10.205.138.9 with SMTP id iq9mr6280150bkc.139.1334164996004; Wed, 11 Apr 2012 10:23:16 -0700 (PDT)
Received: by 10.204.165.66 with HTTP; Wed, 11 Apr 2012 10:23:15 -0700 (PDT)
In-Reply-To: <CBAB69E9.28C5C%matthew.bocci@alcatel-lucent.com>
References: <CABkgnnV8WCeQWiYY9wdVfQM8p5n=S6JxdqQ4gZgkLxg21J8RMw@mail.gmail.com> <CBAB69E9.28C5C%matthew.bocci@alcatel-lucent.com>
Date: Wed, 11 Apr 2012 10:23:15 -0700
Message-ID: <CABkgnnV-HaVLCy+YfCdRJv9ddcUFBP8wv3xqY1bj0Z6yONHsjw@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 17:23:18 -0000

Thanks! Looks good.

On 11 April 2012 09:31, Bocci, Matthew (Matthew)
<matthew.bocci@alcatel-lucent.com> wrote:
> Martin,
>
> On 11/04/2012 16:55, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
>>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?
>
> MB> No. This is a framework/requirements document, and
> the WG made a specific decision early on to separate this from the
> mechanism used to convey preferential forwarding status.
>
>
>>
>>>>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.
>
>
> MB> I propose modifying the paragraph as follows:
>
>  o  Non-revertive behavior MUST be supported, while revertive behavior
>      is OPTIONAL. This avoids the need to designate one PW as primary
> unless revertive
> behavior is explicitly required.
>
>
>>
>>>>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.
>
> MB> I propose modifying the paragraph as follows:
>
>  o  Protection switchover can be initiated from a PE e.g. using
>      a Manual lockout/force switchover, or it may be triggered by a
>      signal failure i.e. a defect in the PW or PSN. Manual switchover may
> be necessary
> if it is required to disable one PW in a redundant set. Both methods MUST
>      be supported and signal failure triggers MUST be treated with a
>      higher priority than any local or far-end manual
>      trigger.
>
>
> Regards
>
> Matthew
>
>
>>
>>--Martin
>