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

Martin Thomson <> Wed, 11 April 2012 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 061AC11E8089 for <>; Wed, 11 Apr 2012 10:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.988
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u-n4Igfqu-3c for <>; Wed, 11 Apr 2012 10:23:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E705E11E809B for <>; Wed, 11 Apr 2012 10:23:16 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so1105099bku.31 for <>; Wed, 11 Apr 2012 10:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id iq9mr6280150bkc.139.1334164996004; Wed, 11 Apr 2012 10:23:16 -0700 (PDT)
Received: by with HTTP; Wed, 11 Apr 2012 10:23:15 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 11 Apr 2012 10:23:15 -0700
Message-ID: <>
From: Martin Thomson <>
To: "Bocci, Matthew (Matthew)" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "" <>
Subject: Re: [Gen-art] GenART review of draft-ietf-pwe3-redundancy-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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)
<> wrote:
> Martin,
> On 11/04/2012 16:55, "Martin Thomson" <> wrote:
>>On 11 April 2012 06:44, Bocci, Matthew (Matthew)
>><> 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
>>> in support of PW redundancy at least support non-revertive operation as
>>> 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
>>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