Thanks! Looks good.
On 11 April 2012 09:31, Bocci, Matthew (Matthew) <[email protected]> wrote: > 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
