Subject: [L2tpext] draft-ietf-l2tpext-l2tp-base-14 : About TieBreaker-loser/winnner

From: Arif <[email-masked]>
Date: Wed, 15 Sep 2004 19:18:53 +0530

Hi,

In Draft draft-ietf-l2tpext-l2tp-base-14
7.2  Control Connection States
..........
.......
wait-ctl-reply  Receive SCCRQ,     Send SCCRP,         wait-ctl-conn
                   lose tie breaker,  Clean up losing
                   SCCRQ acceptable   connection

wait-ctl-reply  Receive SCCRQ,     Send StopCCN,       idle
                   lose tie breaker,  Clean up losing
                   SCCRQ unacceptable connection
wait-ctl-reply  Receive SCCRQ,     Send StopCCN for    wait-ctl-reply
                       win tie breaker       losing connection

5.4.3  Control Connection Management AVPs

Control Connection Tie Breaker (SCCRQ)

The recipient of a SCCRQ must check to see if a SCCRQ has been sent to
the peer; if so, a tie
   has been detected.  In this case, the LCCE must compare its Control
   Connection Tie Breaker value with the one received in the SCCRQ.  The
   lower value "wins", and the "loser" MUST discard its control
   connection, sending a StopCCN if the SCCRQ that it had sent was
   acknowledged by the receiving peer.
-----------------------------------------------------------
Say it mentioned that for Tie Breaker Loser must send StopCCN if SCCRQ
is acknowledge , 
Also in the FSM state it is the winner who should send the StopCCN. 

Please clarify. 

Thanks ,
Arif

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

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 17 Sep 2004 04:04:34 -0400

Arif wrote:

>                   * lose tie breaker*,  Clean up losing
> *wait-ctl-reply  Receive SCCRQ,     Send StopCCN for    wait-ctl-reply*
> *                       win tie breaker       losing connection*
> 
>    lower value "wins", and the* "loser" MUST discard its control*
> *   connection, sending a StopCCN if the SCCRQ that it had sent was*
> *   acknowledged by the receiving peer.*
> *-----------------------------------------------------------*

The table in 7.2 is correct, and the text in 5.4.3 is incorrect. So, to further 
clarify, it should be:

   A               B
SCCRQ ---> <--- SCCRQ
     A wins, B loses
StopCCN --> (for "losing connection")
             <--- SCCRP (for "winning" connection)
SCCCN --->

Thanks for finding this discrepancy, I will try to have it fixed during the 
final window before publication.

- Mark

> 
> 
> *Please clarify. *
> 
> *Thanks ,*
> *Arif*
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: kalyana <[email-masked]>
Date: Mon, 20 Sep 2004 10:57:16 +0530

Hi Mark,

I want some more clarification on Control Connection Tie Breaker .
Why can't we do as below(simialr to L2TPv2 RC 2661) so that FSM is simple

A                                                               B
SCCRQ --->                                     <--- SCCRQ
A wins,                                                      B loses
Ignore received SCRQ                               Clean up,Re-queue SCCRQ
for idle state
                                                          <--- SCCRP (for
"winning" connection)
SCCCN --->

When A wins the i can safely ignore the received the SCCRQ message as it
knows that B will clean it's state to idle and requeue the received SCCRQ
message.
With this approach no need to StopCCN from A to B.

Please let me know your views on this.

Regards,
Kalyan

----- Original Message ----- 
From: "W. Mark Townsley" <[email-masked]>
To: <[email-masked]>
Cc: <
Sent: Friday, September 17, 2004 1:34 PM
Subject: Re: [L2tpext] draft-ietf-l2tpext-l2tp-base-14
:AboutTieBreaker-loser/winnner

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 20 Sep 2004 09:21:21 -0400

> With this approach no need to StopCCN from A to B.

The StopCCN is simply to be more explicit. At best, it is an extra guarantee 
that both sides know who the winner is, just in case one side doesn't implement 
the tie-breaker (or implements it incorrectly!). Given that things really should 
work even without the StopCCN, we could clarify it as a "SHOULD" rather than a 
"MUST."

- Mark

>>The table in 7.2 is correct, and the text in 5.4.3 is incorrect. So, to
> 
> further
> 
>>clarify, it should be:
>>
>>   A               B
>>SCCRQ ---> <--- SCCRQ
>>     A wins, B loses
>>Thanks for finding this discrepancy, I will try to have it fixed during
> 
> the
>