The IESG has approved the following document: - 'Fail Over extensions for L2TP "failover" ' <draft-ietf-l2tpext-failover-12.txt> as a Proposed Standard This document is the product of the Layer Two Tunneling Protocol Extensions Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-failover-12.txt * Technical Summary L2TP is a connection-oriented protocol that requires some shared state between the active endpoints. Some of this shared state is vital for operation but may be rather volatile in nature, such as the sequence numbers used on the L2TP Control Connection or on data connections. This document defines protocol extensions to L2TP to facilitate state recovery after a failure of an L2TP Control Connection Endpoint (LCCE). * Working Group Summary There is consensus in the WG to publish this document. * Document Quality The l2tpext WG has reviewed this document. All concerns raised during review and last call have been addressed. At least one vendor has successfully implemented and deployed this extension. Ignacio Goyret is the WG shepherd for this document. Note to RFC Editor Please add to section 6: Asynchronous notifications for failover and recovery events may be sent by L2TP nodes to network management applications but the specification of the protocol and format to be used for these notifications is out of the scope of this document.' OLD: A device could have three kind of failures: NEW: This document assumes that the actual detection of a failure in the backup endpoint is done in an implementation specific way. It also assumes that failure detection by the backup endpoint is faster than the L2TP control channel timeout between the active and remote endpoints. Typically, active and backup endpoints reside on the same physical device, allowing fast and reliable failure detection without the need to communicate between these endpoints over the network. Similarly, an active endpoint that acts also as the backup endpoint can easily start the recovery once it has rebooted. However, when the active and backup endpoints reside in separate devices, there is a need to communicate between them in order to detect failures. As a result, this document does not provide a complete and interoperable solution for such situations, and additional failure detection protocols, for example [BFD-MULTIHOP], may be needed. A device could have three kind of failures: OLD: [L2TPv3-MIB] Nadeau, Thomas D. and Koushik, Kiran A S., "Layer Two Tunneling Protocol (version 3) Management Information Base", draft-ietf-l2tpext-l2tpmib-base-02.txt, August 2006. NEW: [L2TPv3-MIB] Nadeau, Thomas D. and Koushik, Kiran A S., "Layer Two Tunneling Protocol (version 3) Management Information Base", draft-ietf-l2tpext-l2tpmib-base-02.txt, August 2006. [BFD-MULTIHOP] Katz, D. and Ward, D., "BFD for Multihop Paths", draft-ietf-bfd-multihop-04.txt, _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
