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

[Martin Thomson <[e-mail]>]

Thanks! Looks good.

On 11 April 2012 09:31, Bocci, Matthew (Matthew)
<[e-mail]> wrote:
> Martin,
>
> On 11/04/2012 16:55, "Martin Thomson" <[e-mail]> wrote:
>
>>On 11 April 2012 06:44, Bocci, Matthew (Matthew)
>><[e-mail]> 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
>