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