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 >
- [Gen-art] GenART review of draft-ietf-pwe3-redund… Martin Thomson
- Re: [Gen-art] GenART review of draft-ietf-pwe3-re… Stewart Bryant
- Re: [Gen-art] GenART review of draft-ietf-pwe3-re… Bocci, Matthew (Matthew)
- Re: [Gen-art] GenART review of draft-ietf-pwe3-re… Martin Thomson
- Re: [Gen-art] GenART review of draft-ietf-pwe3-re… Bocci, Matthew (Matthew)
- Re: [Gen-art] GenART review of draft-ietf-pwe3-re… Martin Thomson