Subject: [L2tpext] Comments on draft-ietf-l2tpext-failover-01

From: "Puneet Sood" <[email-masked]>
Date: Tue, 5 Aug 2003 14:26:31 -0400

Hello,

I read the draft recently and had the following questions/comments on it.

I have the November 2002 revision of the draft. Is there a new revision of
the draft?

Comments:

1. Section 4.5 "Failover Session State AVP".
The FSS AVP has one session per AVP. Wouldn't it be more efficient to allow
multiple sessions per AVP? This would be more efficient in terms of the
message size and also the computation required to optionally hide the AVP.
Putting multiple sessions in a single AVP would not preclude sending
multiple FSQ or FSR messages.

2. Creating new sessions in a recovered tunnel.
After a peer fails, it starts recovery by creating a new tunnel and adding
the old tunnel ID AVP to the SCCRQ message. Once the tunnel is up, FSQ and
FSR messages can be exchanged between the peers to synchronize session state
for pre-existing sessions. There is no specific point at which the session
synchronization is known to be complete. My question is: at what point can
new sessions be created on this tunnel? If a new session is created before
session state is synchronized, one end could attempt to create a session
with a session id that is unused on its end but is in use for a session at
the peer. This would cause the peer to fail the session creation request it
receives. By itself this is not a big problem but it would be nice if some
mechanism exists to avoid this problem. If adding a mechanism for this is
not possible some text should be added to the document explaining this
problem.

3. When the two peers of a tunnel are both failover capable and one of the
peers goes down, how long should the other peer save the state for the
tunnel for a possible failover recovery?
It could happen that the peer died and is not coming back for a long long
time. Should the tunnel be deleted as usual when the L2TP tunnel keepalive
mechanism detects the tunnel is down?

4. Old Tunnel ID and Old Local Tunnel ID AVPs.
Both these AVPs are sent in both SCCRQ and SCCRP messages. Sending them in
the SCCRQ should be sufficient. Is there any use of sending them in the
SCCRP also?

5. Section 4.3 Old Tunnel ID AVP.
The packet format is missing the AVP value "old tunnel id".

Thanks,
Puneet

---

From: Vipin Jain <[email-masked]>
Date: Tue, 5 Aug 2003 16:16:55 -0700 (PDT)

thanks for your comments. my comments inline..

> I have the November 2002 revision of the draft. Is there a new revision of
not yet, primarily driven by the interest in the group.
Now since there is some feedback, we'll be happy to incorporate it and send the
update.

> multiple FSQ or FSR messages.
Initially we thought of bundling them in one single AVP, in fact we were
thinking of pairing 'tid, sid' pairs to leverage even more, and as you pointed
out the advantages are obvious, however there are some disadvantages:
- bundling them together mandates all sessions to assume similar AVP
characterstics, like whether to hide them or not, etc. Not that it is a big
deal, but we thought the similar flexibility is provided during session
establishment.
- In a more scalable deployment (i.e. about 30k l2tp sessions per tunnel) we
thought there would be about 1k sessions (on the higher side) that would get
stuck in a dangling state (there are only two such states for incoming calls,
viz. ICCN not ZLB Acked, or ICRP not Acked). About 1k such messages could
easily be handled in one or two FSQ, FSR messages. I mean overhead of about 50%
(please note this is not the CPU overhead, rather more bandwidth consumption)
was okay. I mean, AVP encapsulation in general is not the best for conversation
of bandwidth, but it gives flexibility. Tommorw if we'd like to add more
parameters to the 'Failover Session State AVP'.
- Implementation wise, parsing one AVP for a session looked much simpler. 

> not possible some text should be added to the document explaining this
Good that you brought it up, may be it needs more clarification. Couple of
things:
- New sessions can be created on the tunnel as soon as the new tunnel is
established.
- Old sessions that were in established state are moved (rather, considered
moved by software) to the new tunnel
- Not every such session's state is synchronized. They are either 'dropped' if
they were not in established state, and they are 'moved' if they were in
established state. However, there are situations, as explained in section
2.3.3, some session would be 'dropped' on one side where other side would
consider them in established state and move them. Such sessions, could be
explicitly synchronized by FSQ and FSR messages.
- In such process, some sessions that have inconsistent states on two sides
might result in session establishment failure, which would then help bring the
peers in sync on sessions and their state. This needs to be mentioned,
explicitly to make the text clear, as you indicate.

> tunnel for a possible failover recovery?
As defined by RFC2661 and configured values of control packet timeouts.

> mechanism detects the tunnel is down?
Tunnel keep alives (Hellos), as per rfc2661, would start with 2 second retires
wihch is exponentially backed off and say retried upto 6 times, would take
about a minute to teardown the entire tunnel. This means, entire restart
process shouldn't take more than a minute for a scalable deployment. This was
one of the consideration during the design. Besides, one MUST recover the
sessions way before PPP LCP Echo requests times out - which is typically about
40 seconds.

> the SCCRQ should be sufficient. Is there any use of sending them in the
The failed node puts them in SCCRQ, and its peer puts them in SCCRP.
Getting these values back in SCCRP would validate that peer has associated the
right old tunnel with the new tunnel. Old Local Tunnel ID AVP is kept only for
security purposes. So it would be difficult to guess 2^32 bit unique value (16
bit Old Tunnel ID and 16 bit Old Local Tunnel ID)

> The packet format is missing the AVP value "old tunnel id".
I think we missed it. Thanks for pointing it out.

thanks,
-- vipin

> Puneet

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Vipin Jain <[email-masked]>
Date: Tue, 5 Aug 2003 16:16:55 -0700 (PDT)

thanks,
-- vipin