Re: L2TP failover nits

Ignacio,

Thanks for the review. Some comments inline.

> * Introduction:
>   There are a few things which are not clearly answered in this draft.
>   For instance, who are the players? (I assume there are three)
>   A diagram like this (assuming it is correct) would go a long way to help:
> 
>                                             +--------------+
>                                             | L2TP active  |
>     +----------+                        ----| endpoint (A) |
>     |   L2TP   |                       /    +--------------+
>     | endpoint |-----( IP cloud )-----/
>     |    (R)   |                      \     +--------------+
>     +----------+                       \    | L2TP backup  |
>                                         ----| endpoint (B) |
>                                             +--------------+
> 
>    Using the above diagram's reference points, R, A and B, is it true that
>    the L2TP endpoints are:
>      - R and A for "old tunnels"
>      - A and B for "recovery tunnels" (or is it R and B?)
>      - R and B for "recovered tunnels"
Recovery tunnel is between R and B. The reason for not putting this in the draft is because A and
B resides in the same device and we'd rather not dictate how people model the redundancy in their
device. In many situations (as mentioned in the Introduction) there is a hot standby, even in
absense of such an entity, the recovery could be made - therefore B really need not exist as a
physical card or something, it could be reincarnation of A. I feel the classification like this
should be avoided, please let me know if you still feel otherwise.

> * Terms:
>   The terms "data channel failure" and "control channel failure" are used
>   throughout the draft but there is no explanation what do you mean.
Correct point. I will define them in the Terminology.

> * Page 4:
>   This text needs clarification or a rewrite:
> 
>   "Upon establishing the recovery tunnel two endpoints reset
>    their control and/or data channel; after which recovery tunnel could
>    be torn down."
> 
>   The use of the word "reset" is one of the confusing points here.
> 
The definition of Control/Data plane reset is defined in section 2.2.2, perhaps I'll refer that in
the text to make it clear.

> * Failover Capability AVP:
> 
>   - There is no explanation of what is the meaning of a C-bit set to 0,
>     and it is not clear to me why is the C-bit needed at all. Isn't the
>     presence of this AVP sufficient indication that the sender is capable
>     of understanding failover?
C-bit and D-bit could be set indepdently. If D-bit is set of zero, as per the definition of C-bit,
an end point could not initiate or respond to control channel failure. Then it would send this AVP
only to indicate D-bit capability.

>   - This text (for the D-bit) needs rewording:
> 
>       "This bit is applicable only for the sessions using sequence numbers
>        on the data channel i.e. data channel failure on the system not
>        exhibiting D bit capability could still recover sessions that do
>        not use sequence numbers."
> 
>     The section after "i.e." needs special care.
How about:
"This bit governs the failover capability for sessions using sequence numbers. Sessions that do
not use sequence numbers need not exhibit this capability to successfully recover from the data
channel failure."

If you have a particular text in mind, please feel free to suggest.

> - page 6:
>   "...recovery tunnel...
>    An endpoint SHOULD not send any control message on this tunnel, other than
>    those required to manage the life of the recovery tunnel."
> 
>   I think we should be explicit as to which control messages should or should
>   not be used. An explicit list helps interoperability.
How about:
An endpoint SHOULD only send messages required for the control connection management (section 3.2
[L2TPv2], section 3.1 [L2TPv3]): SCCRQ, SCCRP, SCCCN, StopCCN, StopCCN, HELLO and ZLB-Ack.

> - Tunnel Recovery AVP:
> 
>   How does an endpoint know which tunnels to recover? Should this information
>   somehow have been exchanged between points A and B (in the above diagram)
>   before the failure?
> 
>   The draft should provide some hints. If it is intended to be implementation
>   specific, it should say so.
It is implementation specific, as indicated in section 2.2.1 in the beginning of page 6 ("for
every old tunnel it wishes to recover..").

> There are more nitpicking details, but I really have to run now.
> We can pick this up upon my return in mid-Jan.
Sure.

I will also take care of some of the I-D nits you identified. 

thanks,
-- vipin
















__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com