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

["W. Mark Townsley" <[e-mail]>]

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