Subject: [L2tpext] draft-galtzur-l2tpext-gr-01.txt and draft-ietf-l2tpext-failover-02.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 27 Jan 2004 11:26:11 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: "Tom Mistretta" <[email-masked]>
Date: Tue, 27 Jan 2004 12:10:22 -0500

Certainly failover-02 needed to benefit from feedback and refinement, but this is not unusual.  Vipin and Paul have made great progress offline.  I don't think the "newness" of the technology should be viewed as an obstacle.  

That said, I don't believe it is possible to have a single mechanism that will satisfy the perspectives of both the "static" and "dynamic" models.  If the group believes with deep conviction that these two models should be defined as important separate applications of l2tp, important enough that each perspective warrants such satisfaction, then I think the only way to proceed is to allow two solutions.  Each solution would have to come with a clear explanation of the tradeoffs between them.  At a minimum, the failover-02 draft will have to be enhanced to take care of v3.

I think it is most unfortunate for the (nay, any) protocol to have more than one mechanism for failure recovery.  It sets a bad precedent, as someone in the future may think of another l2tp application that benefits from yet another recovery mechanism.

Tom

---

From: "Tom Mistretta" <[email-masked]>
Date: Tue, 27 Jan 2004 12:10:22 -0500

Tom