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

From: "Reinaldo Penno"<[email-masked]>
Date: Thu, 28 Feb 2002 07:48:19 -0800

>-----Original Message-----
>From: W. Mark Townsley [mailto:[email-masked]]
>Sent: Thursday, February 28, 2002 1:04 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [L2tpext] Comments on draft-vipin-l2tpext-failover-01.txt
>
>
>
>
>> Reinaldo Penno wrote:
>> 
>> 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.
>
>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.

I agree, I wasn't just pointing out it shouldn't be a MUST on draft, but a
SHOULD with a comment saying that if the AVPs change the tunnel might not be
recovered.

regards,

Reinaldo

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 28 Feb 2002 17:19:40 +0100

> SHOULD with a comment saying that if the AVPs change the tunnel might not be

The latter is almost a MUST, in which case I lean more to making it a MUST.
MUSTs are good for interoperability, SHOULDs and MAYs are not. If its just a
SHOULD, then it could work with some vendors, and not with others. That's never
fun.

> Reinaldo

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