Re: [Gen-art] GenART review of draft-ietf-pwe3-redundancy-06
"Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> Wed, 11 April 2012 13:45 UTC
Return-Path: <matthew.bocci@alcatel-lucent.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 92A6B21F8627 for <gen-art@ietfa.amsl.com>; Wed, 11 Apr 2012 06:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.649
X-Spam-Level:
X-Spam-Status: No, score=-109.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 XXsT8Gjrqyja for <gen-art@ietfa.amsl.com>; Wed, 11 Apr 2012 06:45:32 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE9921F8616 for <gen-art@ietf.org>; Wed, 11 Apr 2012 06:45:32 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3BDhI0I026807 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Apr 2012 15:45:27 +0200
Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 11 Apr 2012 15:44:51 +0200
From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
To: Martin Thomson <martin.thomson@gmail.com>, "draft-ietf-pwe3-redundancy.all@tools.ietf.org" <draft-ietf-pwe3-redundancy.all@tools.ietf.org>
Date: Wed, 11 Apr 2012 15:44:45 +0200
Thread-Topic: GenART review of draft-ietf-pwe3-redundancy-06
Thread-Index: Ac0X6URP0RH2aO40Sa2RmNFdTPZyxA==
Message-ID: <CBAA1236.28476%matthew.bocci@alcatel-lucent.com>
In-Reply-To: <CABkgnnWefLUiSfxyEZpMck9moFeu7wHWk9-yAgHKDukLAt7EiQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: "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 13:45:33 -0000
Martin, Many thanks for your review. Please see below for some comments and proposed amendments to the draft. Best regards, Matthew On 16/03/2012 03:06, "Martin Thomson" <martin.thomson@gmail.com> 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? 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. " > >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 as the primary such that you always revert to it when it comes back up and qualifies for active state. I believe the consensus when the requirements were discussed was that the primary mechanism will be optional and that the basic mode of operation will be to just switch to the next available PW and stick to it until an event causes a new selection to be performed. > >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. 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. draft-ietf-pwe3-redundancy-bit defines a force switchover bit to enable this coordination, and its operation is described in Section 6.3.1 of that draft: " f. If while waiting for the acknowledgment, the requesting endpoint detects that the requested PW went into DOWN state locally, and could use an alternate PW which is UP, it must perform the following: i. Abort the timer. ii. Issue a new request to switchover to the alternate PW. iii. Re-start the timer. g. If, while waiting for the acknowledgment, the requesting endpoint detects that the requested PW went into the DOWN state locally, and could not use an alternate PW which is UP, it must perform the following: i. Abort the timer. ii. Send an update status notification message with the 'Preferential Forwarding' status bit unchanged and the 'request switchover' bit reset for the requested PW. " > >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. MB> Agreed. I propose adding "...if both modes are supported" to the end of the sentence. > >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"). MB> Agreed. In some cases the figures follow established PWE3 conventions which are '...' for PWs and '===' for PSN tunnels, but it is not at all consistent. I will try to redraw the diagrams with better consistency. > >4.2 has an empty bullet. MB> Thanks > >Not expanded on first use: PSN, LDP MB> Thanks. >
- [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