Subject: RE: [L2tpext] Please comment on draft-galtzur-l2tpext-gr-01.txt

From: Sharon Galtzur <[email-masked]>
Date: Wed, 21 Jan 2004 16:06:02 +0200

Hello Paul and all,
See my comments inline
 
Sharon Galtzur

-----Original Message-----
From: Paul W. Howard [mailto:[email-masked]]
Sent: Wednesday, January 14, 2004 9:25 PM
To: Sharon Galtzur
Cc: W. Mark Townsley; [email-masked]
Subject: Re: [L2tpext] Please comment on draft-galtzur-l2tpext-gr-01.txt

Sharon,

Thanx for your responses.   Please see further comments inline ([pwh])

Thanx,

Paul Howard

Sharon Galtzur wrote:

Hello all,

See my response in the mail body.

Sharon Galtzur

-----Original Message-----

From: Paul W. Howard [ mailto:[email-masked]
<mailto:[email-masked]> ]

Sent: Friday, January 09, 2004 4:59 PM

To: W. Mark Townsley

Cc:  [email-masked] <mailto:[email-masked]> 

Subject: Re: [L2tpext] Please comment on 

draft-galtzur-l2tpext-gr-01.txt

I have a few questions/concerns in regards to this draft:

1) This proposal presents what appears to be an entirely different 

mechanism than that proposed in the v2 draft 

(draft-vipin-l2tpext-failover-02.txt).   It would seem to be 

important 

that we attempt to have a single mechanism for both v2 and v3 

or to at 

least minimize the differences to those that are unavoidable.

In LDP there is exactly the same occurrence - 

RFC 3478: Graceful Restart Mechanism for Label Distribution Protocol 

RFC 3479: Fault Tolerance for the Label Distribution Protocol (LDP) 

This draft follows the model presented in RFC 3478 with adaptation to L2TPv3

[pwh] My understanding is that 3478 and 3479 present signficantly different
approaches to the problem of dealing with a failed endpoint - 3478 recovers
by learning from the non-failed endpoint (graceful restart) whereas 3479
recovers by state replication on the failed endpoint.    Both your draft and
Vipin's would seem to fall into the category of graceful restart (i.e.
learning from the non-failed endpoint).   Both of the l2tp drafts deal with
trying to recover key pieces of the control plane that are not normally
obtainable from the forwarding database - the sequence numbers of the
control connection and the state (established or non-established) of each of
the sessions.   It would thus seem reasonable to resolve the differences
between these drafts and produce as common an approach as possible to
graceful restart.

[pwh] btw - I misquoted the current version of the other draft - it's
draft-ietf-l2tpext-failover-02.txt

2) I don't understand the basic reset of the sequence number 

space for 

the control connection.   Is this setting up a replacement tunnel or 

attempting to reset the sequence numbers of the extant tunnel?

The tunnel is restarted almost exactly as in

draft-ietf-l2tpext-l2tp-base-11.txt

One technical difference is the added AVP to advertise the graceful restart

capability.

Another difference is that while restarting the sessions certain information

need 

to endure the restart (i.e. Session ID, Cookie value etc) that will allow

the data path

to continue without interruptions.

[pwh] I'm not entirely clear on your answer.   There would seem to be two
basic approaches to recovery of the control connection - one is to establish
an entirely new control connection and eventually transfer the sessions from
the old control connection to the new control connection; the other is to
reset the extant control connection,   It's not clear to me from your answer
or the draft which direction you are proposing.   So, when I attempt to
restart a control connection by sending an SCCRQ with the GR AVP and a
non-zero recovery time, what is the value of the Assigned Control Connection
Id AVP?  Is it the same as the one from the initial establishment (implies
reset of the extant control connection) or a new value (implies a recovery
control connection and transfer of the sessions from the old to the new)
 
[Sharon Galtzur] I agree this is indeed missing from the draft - 
The pro and con of each approach are as follow: 
1. If we remember the the CC ID - we gain a bit more confidence when we
looking up the CC in the LCCE that wasn't restart, because we have more
information
    to compare to when recovering the CC. The drawback is that the restarted
LCCE must have the means to remember this information (since this
information is NOT 
    a part of the data path and hence is not transferred to the data path
parts of the system). 
2. If we don't remember the CC ID - we lose some confidence when we looking
up the CC (but really not more then when doing normal restart). The gain is
that there is 
    no need for this information to be persistent.
 
Currently I would think that not remembering the CC ID from restart to
restart is preferred because it is less restrictive and is more close to the
non-graceful restart requirements. 
 
I would like to hear from others what they think before I update the draft.

3) It would appear that there is a linear relationship between the 

number of packets required for the fail over and the number of 

established sessions.   This would seem to present issues 

with scalability.

The behavior of the graceful restart proposal is not worse then normal start

of 

L2TPv3 (since the mechanism of the graceful and non graceful restart are

practically the same). 

If there is scalability issue in this proposal it is inherit to the whole

L2TP model and not restricted to 

the proposed graceful restart

[pwh] IMHO, there is a scability problem that needs to be addressed.    When
a failover occurs, the failed endpoint is in the process of trying to
recover it's state not only for L2TP, but for all other applications running
in the failed endpoint (e.g. IP, BGP, PPP, AAA, etc.).   It is a time of
maximum stress on the failed endpoint coupled with restrictive time limits
(e.g. BGP neighbor notifications).   Failover processes needs to be designed
with minimal resource consumption.    This draft proposes 'n' packets to be
sent from the failed endpoint to the non-failed endpoint where 'n' is the
number of sessions between the 2 endpoints.   This results in 10's of
thousands if not 100's of thousands of packets to complete the recovery.
In order to avoid this issue, it would seem that the session recovery needs
to be able to recover by packing multiple session recoveries per packet -
thus reducing to n/m packets where m is the number of recoveries per packet.
As the primary recovery requirement for the session is to confirm that both
endpoints believe the session to be in established state, this could reduce
to sending the session id's of the established sessions from the failed
endpoint to the non-failed endpoint followed by the non-failed endpoint
sending back the session ids of the established sessions based on the
intersection of what it received from the failed endpoint and it's local
database.   Assuming say 256 session ids packed in a single packet (1K of
data), then we end up with 2 * n / 256 packets to recover.   Thus with
100,000 sessions only 782 packets are required to recover instead of
100,000+ packets.  
  
[Sharon Galtzur] The same can be said for the current L2TP non-graceful
restart. It is probably even more pressing since there is no data flow till
the connections are 
restarted. The big advantage I see in this approach is that it is so similar
to normal L2TP model. This will allow implementers of L2TP stacks to
implement one model of establishing sessions instead of 2. 
I would suggest that if there is a real concern of connecting 100k
connection between 2 LCCE we should re-examine the possibility of
establishing multiple sessions connection using 1 packet instead of
requiring 1 packet per session in the non-graceful restart and then adopt it
to the graceful restart mode. 

Thanx,

Paul Howard

W. Mark Townsley wrote:

I would like to ask that interested parties review the 

following draft 

"Layer Two Tunneling Protocol (Version 3) Graceful Restart" and 

provide comments to the list. This draft was originally 

presented in 

Vienna, and updated based on comments during the meeting.

http://www.ietf.org/internet-drafts/draft-galtzur-l2tpext-gr-01.txt
<http://www.ietf.org/internet-drafts/draft-galtzur-l2tpext-gr-01.txt> 

The authors would like to make this a WG document.

Thanks,

- Mark

_______________________________________________

L2tpext mailing list

[email-masked] <mailto:[email-masked]> 

https://www1.ietf.org/mailman/listinfo/l2tpext
<https://www1.ietf.org/mailman/listinfo/l2tpext> 

_______________________________________________

L2tpext mailing list

[email-masked] <mailto:[email-masked]> 

https://www1.ietf.org/mailman/listinfo/l2tpext
<https://www1.ietf.org/mailman/listinfo/l2tpext>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 26 Jan 2004 21:27:16 +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

[email-masked]

---

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

Thanks,

- Mark