Subject: RE: [L2tpext] Comments on draft-vipin-l2tpext-failover-01.txt

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 27 Feb 2002 15:13:22 -0800

Hello Mark/Vipin,

inline...

>-----Original Message-----
>From: W. Mark Townsley [mailto:[email-masked]]
>Sent: Monday, February 25, 2002 3:13 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [L2tpext] Comments on draft-vipin-l2tpext-failover-01.txt
>
>
>
>
>2.0 Failover Protocol
>
>The failover protocol allows an endpoint to specify its failover 
>capabilities when it establishes a tunnel. Based on failover 
>capabilities, two end points learn if a tunnel and its 
>sessions require 
>recovery. 
>
>WMT How about "support" recovery instead of "require" recovery

Agreed

>
>Upon failure, the failed endpoint initiates a new tunnel for 
>every old tunnel that includes a new AVP, Old Tunnel ID AVP. 
>
>WMT Above sentence is easy to misread. You are not initiating 
>a new tunnel for
>every tunnel that included the AVP; you are initiating a new 
>tunnel with a new
>AVP for every old tunnel. A difficult but important 
>grammatical difference.

I also agree. Actually the first time I read this sentence I was thiking
"when we changed the proposal to establish all these tunnels"?

>
>
>2.3.1. Failed Endpoint's Behavior 
>
>It establishes a new tunnel as specified in [L2TP] with following 
>considerations:
>
>o  SCCRQ and SCCCN messages contain the same AVPs that were originally 
>   present in the old tunnel.
>
>o  It must include the Old Tunnel Id AVP and Old Local Tunnel Id AVP,
>   as defined in section 3.0, in the new SCCRQ. 
>
>WMT "In addition to the AVPs originally present in the old 
>tunnel, it must
>include ..."

hum...I might be wrong but I tought we discussed this many moons ago...I
thought that including the same AVPs wasn't mandatory. If when you try to
recover you (do not) include some AVPs it's a admin decision. Maybe you
changed some configuration in the meantime. 
>
>o  If the new tunnel is rejected then it MUST assume that recovery has 
>   failed and should clear the tunnel on its end.
>
>o  Once failover is detected, control packets received prior to  
>   synchronization of the tunnel should be ignored. The tunnel is said 
>   to be in synchronized state once the establishment process is 
>   complete.
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 28 Feb 2002 10:03:48 +0100

> Reinaldo Penno wrote:
> I also agree. Actually the first time I read this sentence I was thiking "when
> we changed the proposal to establish all these tunnels"?
> 
> >
> >

I don't remember the outcome of our discussion many moons ago.

But, as far as what I am thinking today, my only fear in allowing this is that
there might be some session specific state that is defined at the tunnel
initiation level that might not get updated when the new tunnel comes up and
takes over all of the sessions from the old tunnel. It just seemed simpler to
say that the new tunnel has to be the same as the old tunnel.

> >   to be in synchronized state once the establishment process is

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