Protocol Action: 'Fail Over extensions for L2TP "failover"' to Proposed Standard

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce