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

From: Stewart Bryant <[email-masked]>
Date: Thu, 05 Apr 2012 18:02:25 +0100

Authors

Please can you answer or address these comments

Thanks

Stewart

On 16/03/2012 03:06, Martin Thomson 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?
>
> 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.
>
> 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.
>
> 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.
>
> 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").
>
> 4.2 has an empty bullet.
>
> Not expanded on first use: PSN, LDP
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 11 Apr 2012 15:44:45 +0200

Martin,

Many thanks for your review.

Please see below for some comments and proposed amendments to the draft.

Best regards,

Matthew

>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. "

>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.
>be treated with lower priority_, then that is definitely

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.
"

>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.

>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.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Apr 2012 08:55:22 -0700

> 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?

> baseline. To implement a revertive behaviour, you will need to designate

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

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

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 11 Apr 2012 18:31:18 +0200

Martin,

>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.

>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.

>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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Apr 2012 10:23:15 -0700

Thanks! Looks good.