[L2tpext] draft-galtzur-l2tpext-gr-01.txt and draft-ietf-l2tpext-failover-02.txt
"W. Mark Townsley" <townsley@cisco.com> Wed, 28 January 2004 00:10 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02594 for <l2tpext-archive@lists.ietf.org>; Tue, 27 Jan 2004 19:10:56 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldHO-0001Wq-G3; Tue, 27 Jan 2004 19:10:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlDOS-0006wr-68 for l2tpext@optimus.ietf.org; Mon, 26 Jan 2004 15:31:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19260 for <l2tpext@ietf.org>; Mon, 26 Jan 2004 15:31:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlDOL-0002IG-00 for l2tpext@ietf.org; Mon, 26 Jan 2004 15:31:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlDMN-0002Ca-00 for l2tpext@ietf.org; Mon, 26 Jan 2004 15:29:28 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AlDLF-00027H-00 for l2tpext@ietf.org; Mon, 26 Jan 2004 15:28:18 -0500
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0QKRJ5g022979; Mon, 26 Jan 2004 15:27:19 -0500 (EST)
Received: from cisco.com (rtp-vpn2-490.cisco.com [10.82.241.234]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWM71071; Mon, 26 Jan 2004 12:27:17 -0800 (PST)
Message-ID: <40157824.4080104@cisco.com>
Date: Mon, 26 Jan 2004 21:27:16 +0100
From: "W. Mark Townsley" <townsley@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sharon Galtzur <sharon@AXERRA.com>, "'Paul W. Howard'" <phoward@juniper.net>, l2tpext@ietf.org
References: <AF5018AC03D1D411ABB70002A509132601085FED@TLV1>
In-Reply-To: <AF5018AC03D1D411ABB70002A509132601085FED@TLV1>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [L2tpext] draft-galtzur-l2tpext-gr-01.txt and draft-ietf-l2tpext-failover-02.txt
Sender: l2tpext-admin@ietf.org
Errors-To: l2tpext-admin@ietf.org
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
I would like to try and offer a level set here for continuing the discussion. I see that these two drafts are trying to solve similar problems, though perhaps optimized differently. Fundamentally, both intend to address the restablishment of control connection and session state for L2TP during a failure scenario. That may mean failover from an active to standby RP, or the restart of an RP while continuing to forward packets. For the most part, either mechanism could be made to work for L2TPv3 or L2TPv2. I think there are obvious benefits if we can have a single mechanism for both. The only fundamental difference I see between the two protocols themselves which might affect the design of the associated restart method is that in L2TPv3 the Control Connection ID is *not* carried in the L2TP Data Message Header, and in L2TPv2 the analogous Tunnel ID *is* carried in the L2TP Data Message Header. Thus, v3 has the advantage over v2 in that it can restart with a different Control Connection ID without affecting the forwarding plane. This difference is tangible, but would hopefully not prohibit convergence on a common mechanism. I believe the more fundamental reason we see two divergent solutions is that each is being targeted to different deployment environments. draft-galtzur-l2tpext-gr-01.txt is targeted at the current L2TPv3 space, while draft-ietf-l2tpext-failover-02.txt is targeted at the more mature RFC2661 L2TPv2 space. As such, draft-galtzur-l2tpext-gr-01.txt is optimized for an environment which is: - Provisioned in a relatively static manner - Has a fairly small number of sessions per LCCE - Largely addresses restart of a single RP while continuing to forward traffic on a separate dataplane draft-ietf-l2tpext-failover-02.txt is optimized for an environment which is: - Provisioned in a largely dynamic manner - Has a large number of sessions per LCCE - Addresses restart of an RP, or failover to a secondary RP or node, where some amount of session and control connection state may be checkpointed (e.g., beyond that necessary for forwarding alone), and where traffic flow may be interrupted during failover. One might argue that, over time, the deployment environment of L2TPv3 will look more and more like that of L2TPv2. e.g., higher density, more dynamic provisioning via auto-discovery or NMS systems, etc. Thus, some of the scaling benefits of draft-ietf-l2tpext-failover-02.txt could become more relevant as well. That said, I don't believe the draft-ietf-l2tpext-failover-02.txt has all the kinks worked out in it. draft-galtzur-l2tpext-gr-01.txt has the advantage of being quite simple, is relatively complete, and requires very little (if any) state checkpointing beyond that which could be gleaned from the still-active forwarding plane which is assumed to be present. It's perfectly adequate for cases where you aren't concerned about how fast the sessions recover (and if you have a forwarding plane that is still passing packets for fairly static sessions, why should you care?). Authors, please let me know if I have not articulated the situation accurately. Next step is to try and come up with a single method (or very close to a single method) that operates with both versions of L2TP. Thanks, - Mark _______________________________________________ L2tpext mailing list L2tpext@ietf.org https://www1.ietf.org/mailman/listinfo/l2tpext
- [L2tpext] Please comment on draft-galtzur-l2tpext… W. Mark Townsley
- Re: [L2tpext] Please comment on draft-galtzur-l2t… Paul W. Howard
- RE: [L2tpext] Please comment on draft-galtzur-l2t… Sharon Galtzur
- Re: [L2tpext] Please comment on draft-galtzur-l2t… Paul W. Howard
- RE: [L2tpext] Please comment on draft-galtzur-l2t… Sharon Galtzur
- [L2tpext] draft-galtzur-l2tpext-gr-01.txt and dra… W. Mark Townsley