Lars Eggert <l...@eggert.org> writes:
Sorry for the top post. The text below is not sufficient. 8084 gives guidance on how to specify a CB , but doesn’t itself specify a solution that can just be pointed to. This document needs to define how, based on the guidance in 8084, a CB should be implemented for this specific protocol.
Hi Lars, That was not required of pseudowires, I'm wondering why we are different here. We do in fact indicate that congestion reports should be enabled when implementing a circuit breaker to provide the sender with the RFC8084 required information. How sophisticated a vendor makes their circuit breakers (e.g., the types of controls they offer to the user etc), is a method of market differentiation. Normally IETF does not limit this unless it is required for protocol interoperability. If you're requiring that we give an example of a simple CB implementation for vendors incapable of figuring this out (I'm not sure how they managed to implement the rest of the protocol w/o being able to do this but anyway..)? I can add the following text if it will clear the DISCUSS. One example of a simple slow-trip circuit breaker (CB) an implementation may provide would utilize 2 values, the amount of persistent loss rate required to trip the CB and the required length of time this persistent loss rate must be seen to trip the CB. These 2 value are required configuration from the user. When the CB is tripped the tunnel traffic is disabled, and an appropriate log message or other management type alarm is triggered indicating operate intervention is required. Thanks, Chris.
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
