Subject: RE: [Dime] question on Fail-over

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 13 Sep 2006 17:17:02 -0700

Tolga Asveren <mailto:[email-masked]> scribbled on Wednesday,
September 13, 2006 6:14 AM:

> Prasad,
> 
> I would say the second one. The session-Id for a single session must
> stay the same and session-Id must be globally unique. I don't see a
> reason, why those principles would be violated with the second
> option.   

I don't think that this is a realistic question, nor one that Diameter
fail-over was designed to deal with (unless the "client" is actually an
agent).  If the Diameter client is a NAS/switch/etc., presumably it has
some kind of _physical_ connection to _its_ client_, so how is it
supposed to "fail-over" this physical connection (unless that connection
is to both Diameter clients simultaneously all the time)?

> 
>     Thanks,
>     Tolga
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 13, 2006 5:11 AM
> To: [email-masked]
> Subject: [Dime] question on Fail-over
> 
> 
> Hi,
> I have a question on behavior of server at the time of Fail-over of a
> client. I will try to explain my doubt with the help of following
> scenario.  
>             1. Assume that there are two diameter client Nodes, one
> configured as ACTIVE and other as STANDBY. Similarly there are two
> server Nodes configured.  
>             2. There are some active sessions (either authorization or
> accounting) are on going between ACTIVE Client Node and ACTIVE server
> Node. 
> According to RFC 3588, all the messages in these sessions will have
> Origin-Host as say, 'active.example.com' and Session-Id AVP as
> 'active.example.com;XXXX;YYYY'.  
>             3. While there are active sessions, suppose ACTIVE client
> Node goes down, and the STANDBY starts to take over the sessions and
> tries to send messages to server.  
> My doubt is:
>             In step 3, when STANDBY client starts handling the ACTIVE
> sessions, what will be the session-Id AVP? Will it be
> 'standby.example.com;XXXX;YYYY' ,since this time messages are
> originated from the STANDBY client. or will it be the same as
> previous('active.example.com;XXXX;YYYY'). If it is first one, is it
> allowed at server Node? I think the server considers this as an
> error, since with in the same session messages with two different
> Session-Id AVPs are not allowed. If it is second one, then the
> Origin-Host AVP (in this case standby.example.com) will be different
> than in the host-identity portion of the session-Id AVP and I think
> this is not allowed according Base RFC. So, What will be behavior at
> server Node in this scenario.          
> 
> 
> Any feed back/response is highly appreciated.
> 
> 
> Thanks
> PRASAD.
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime

Hope this helps,

~gwz

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

---

From: <[email-masked]>
Date: Thu, 14 Sep 2006 09:23:59 +0530

Inline...
-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 5:47 AM
To: [email-masked]
Cc: [email-masked]; Tolga Asveren
Subject: RE: [Dime] question on Fail-over

[PRASAD]I agree with you that Diameter Fail-over was not designed to
deal with this, but the question is not a hypothetical, and it is the
real time issue we are 
Currently facing. What my real intention was to know how the server side
implementation should behave in these kind of scenarios. The server we
are currently interoperating is throwing error.

Thanks
Prasad.

Hope this helps,

~gwz

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.3/446 - Release Date:
9/12/2006

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 14 Sep 2006 09:14:52 -0400

Glen,

For certain application types/configurations this may not make sense but I
believe there are applications where the concept is applicable.

I agree with you that this behavior is not something related with Diameter
base protocol failover but failover on application level.

     Thanks,
     Tolga

> Sent: Wednesday, September 13, 2006 8:17 PM