Re: [L2tpext] WG last call for draft-ietf-l2tpext-failover-05.txt

This looks like a very good document to me, please find a couple of
comments/queries:

1.
      2.2.1 Recovery tunnel establishment

         corresponding old tunnel.  An endpoint SHOULD not send any
         control message on this tunnel, other than the messages to
         establish and tear down the tunnel itself.

***CP: I know this was updated with the "and tear down" to clarify about
***CP: StopCCN. Maybe just a nit, I wonder however if "establish,
***CP: keepalive and tear down" is more complete to include ZLB as well.
***CP: Or possibly simpler enumerate the allowed control messages: SCCRQ,
***CP: SCCRP, SCCCN, StopCCN, ZLB Ack and Explicit-Ack (for L2TPv3
***CP: only).

2.
         Tunnel Recovery AVP for L2TPv3 tunnels:
[snip]
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Recover Tunnel Id                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Recover Remote Tunnel Id                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

***CP: s/Tunnel Id/Control Connection ID/
***CP: Same clarification between tunnel id and control connection id in
***CP: the following 2 or 3 para (only mentions tunnel id).

3.
         Id and responds with an SCCRP. It MUST terminate the tunnel if:
         - Recover Tunnel Id or Remote Recover Tunnel Id is unknown.
         - Non failed endpoint did not indicate it was failover capable.
         - The L2TP version of recovery tunnel is different from the

***CP: What if the _failed_ endpoint did not indicate it was failover
***CP: capable when established the "old tunnel"? In such case:
***CP: 1. non-failed would not know peer's Recovery time, and any
***CP: assumption for it could result in extended downtime.
***CP: 2. is seems could open the door for a malicious party
***CP: impersonating a failed party?
***CP: So probably should/must terminate the recovery tunnel of the
***CP: failed endpoint did not indicate was failover capable?

4.
         tunnel. If, for any reason, the failed endpoint could not
         establish the recovery tunnel then it MUST silently clear the
         recovered tunnel and sessions within, assuming the recovery
         process has failed.

         Any control packet received on the recovered tunnel, before
         control channel reset, MUST be silently discarded.

***CP: The "recovered tunnel" in those 2 sentences is in fact the "old
***CP: tunnel" at this point, right? If the recovery tunnel
***CP: establishment fails then the old tunnel never makes it to
***CP: recovered, correct?

5.
         An endpoint MUST use tie breaker AVP (section 4.4.3 [L2TPv2]
         and section 5.4.3 [L2TPv3]) in the setup of the recovery tunnel

***CP: the "tie breaker AVP" would be the "Control Connection Tie
***CP: Breaker AVP" for L2TPv3; some other parts of the document make
***CP: the distinction between different named v2/v3 AVPs.

6.
      2.2.1 Recovery tunnel establishment

***CP: What are the guidelines for including Failover Capability AVP in
***CP: the Recovery Tunnel SCCRQ/SCCRP establishment? MUST NOT be used?
***CP: Or use the values included in the Failover Capability AVP
***CP: for the Recovery Tunnel as applicable for the recovered tunnel,
***CP: to be used in a subsequent failure?

7.
   2.1 Pre Failover Operation

      The D bit, when set indicates that an endpoint is capable of
      resetting Nr value based on received Ns value(s) from one or more
      'out of order but in sequence' packets from the peer.  This bit is
      applicable only for the sessions using sequence numbers on the
      data channel i.e. data channel failure on the system not

      2.2.2 Control and Data Channel Reset

         numbers and if data channel has failed over. Failed endpoint
         resets its Ns value to zero, where as non failed endpoint could
         continue to use the Ns values it was using previously. To reset
         Nr values during failover, if an endpoint receives 'n' out of
         order but in sequence packets then it MUST set the Nr value
         based on the Ns value of the incoming packets, as suggested in
         Appendix C [L2TPv3]. The value of 'n' should be configurable.

***CP: Nit comment: I wonder if these paragraphs should say "expected
***CP: sequence number" instead of Nr and Sequence Number instead of Ns
***CP: for data channel, to make it clear is not the control connection
***CP: Nr/Ns for L2TPv3. Or note what Nr/Ns are referring to in L2Tpv3,
***CP: as sequencing fields do not have that name.

8.
   2.3 Session State Synchronization
      Step2: Both endpoints SHOULD identify the sessions that might have
      been in inconsistent states, perhaps based on data channel
      inactivity.

***CP: Over what period is data channel inactivity measured? In any case
***CP: it may not be an accurate indicator of inconsistency, a silent
***CP: session may be consistent and a session receiving data packets
***CP: may be inconsistent. Shouldn't FSS for all sessions instead?

9.
      Step3: An endpoint sends Failover Session Query (FSQ) message,
      message type 21, to query the state of stale sessions on its peer.
      An FSQ message MUST include at least one Failover Session State
      (FSS) AVPs.  An endpoint MAY send another FSQ message on the

***CP: It may be useful to make explicit what AVPs MAY/MUST in FSQ. MUST
***CP: Message Type, MAY Message Digest and MUST one or more Failover
***CP: Session State AVPs. Right? Additionally, in the FSS description,
***CP: it would be useful to specify that FSS can only be used in FSQ
***CP: and FSR messages.

10.
      Before all sessions are synchronized using FSQ/FSR mechanism, if
      an endpoint receives an ICRQ for a session it believe is already
      in established state, it MUST respond to such ICRQ with a CDN,
      setting Assigned/Local Session ID AVP ([L2TPv2] section 4.4.4,
      [L2TPv3] section 5.4.4) to its local session id, and clear the

***CP: The first line seems to be the first mention of FSR (the name
***CP: "Failover Session Response" is first introduced further down). It
***CP: would be useful to expand the name before and detail which AVPs
***CP: MAY/MUST in FSRs: MUST Message Type, MAY Message Digest and MUST
***CP: one or more Failover Session State AVPs. Correct?

11.
4.0 Security Considerations
   The failover mechanism described here leaves a some room (1 in 2^32)
   for an intruder to discover the old tunnel id of an existing tunnel

***CP: This probability number seems only for L2TPv2. More importantly
***CP: though, this section should include what to can be done to
***CP: minimize the exposure. At least, control message security
***CP: mechanisms must be considered, specifically for mutual endpoint
***CP: authentication (for tunnel establishment for v2 and also for
***CP: control message auth for v3). Additionally, an impersonator may
***CP: try to create a recovery tunnel clearing C and D bits to drop the
***CP: old tunnel/sessions.

12.
Appendix A

***CP: The 4 Appendices are most useful !!!

13.
      -  The mechanism should be backward compatible; i.e. it should not
      redefine existing behavior of [L2TP] compliant systems.

***CP: There's no [L2TP] reference, is that v2 only or both?

14.
Appendix B
   from recovering multiple tunnels in parallel. It also allows an
   endpoint from sending multiple FSQs to recover quickly.

***CP: In addition, from including multiple FSSs in FSQ and FSR to
***CP: recover quickly.

I hope these help !

--Carlos.

Circa 7/31/2005 12:32 PM, da Silva, Ronald said the following:
> This is the last call for draft-ietf-l2tpext-failover-05.txt.  Please
> review and send comments to this list.
> 
> Last call will end August 15th, 2005.
> 
> Thanks!
> -ron
> 
> _______________________________________________
> L2tpext mailing list
> L2tpext@ietf.org
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext