Martin, On 11/04/2012 16:55, "Martin Thomson" <[email protected]> wrote:
>On 11 April 2012 06:44, Bocci, Matthew (Matthew) ><[email protected]> 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
