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

[Stewart Bryant <[e-mail]>]

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