Re: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft"ResourceManagement Extensions"

[Tony Zhang <zhangtao_hw at huawei.com>]

HI All:
     some querys:
1)if Failover,both nodes share same Host name or not.if use different Host name,how to route the message.
if share both Host name,maybe establish connects connect two node is ok.
2)after audit,should restore the session state or not,In the case of failover without replication if want restore the sesssion,how long will be permit. a few minustes or hours.
3)should server or client,save some transparent data on each other.
4)session state  synchronization maybe is mandatory,but only check the session active or not maybe is simply,if want restore session state then it will complex.
Thanks
 Tony

some comments see inline:
----- Original Message ----- 
From: "Tolga Asveren" <asveren at ulticom.com>
To: <dime at ietf.org>; <aaa-wg at merit.edu>
Sent: Thursday, June 22, 2006 12:13 AM
Subject: RE: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft"ResourceManagement Extensions"


> A few quick questions/comments about this interesting draft:
> 
> 1) 2.1
> If there is no synchronization on client side, wouldn't using
> Origin-State-Id AVP (RFC3588 8.16)solve the problem described in this
> section? After failure/restart/takeover client can populate Origin-state-Id
> AVP with a value bigger than the one used before the failure and server
> should clean up previous sessions.
[Tony]Origina-State-Id AVP maybe only use for check the session state synchronization or not.
cannot use for state recovery
> 
> 2) 2.1.1
> SCTP multi-homing does not provide host redundancy -unless one has a
> distributed SCTP implementation, which probably is not realistic or
> something I would recomend to anybody-
> 
> 3) 2.1.1
> Is mentioning about IP address takeover really necessary? IMO, Diameter
> entities are addressed by Diameter Identities, hence what is important is
> that a backup assuming the identity of a failed active instance -which
> doesn't require IP takeover-.
> 
> 4) As a generic comment, I always thought this type of functionality is to
> be addressed by specific applications themselves, e.g. DCCA, if there is
> such a need.
> Let's consider DCCA:
> When there is an open session, client will send from time to time
> CCR(Update) or CCR(Terminate), which would be replied with "DIAMETER UNKNOWN
> SESSION ID", if server failed/restarted etc... and corresponding state did
> not survive. Upon receipt of such an error answer, client can clean up its
> own state for this session.
> Similarly server can send RAR to client, if CCR(Update) is not received in a
> timely manner. If state did not survive on client side after a failure,
> client would reply with "DIAMETER UNKNOWN SESSION ID" and server can clean
> up session state (Alternatively server may choose not to send RAR and may
> abort the session)
> 
> AFAICS, for the above example, all cases are covered.
> 
> The question is, whose responsibility is that type of fucntionality, base
> protocol or applications.
> 
>     Thanks,
>     Tolga
> 
> > -----Original Message-----
> > From: Tschofenig, Hannes [mailto:hannes.tschofenig at siemens.com]
> > Sent: Wednesday, June 21, 2006 11:33 AM
> > To: Bernard Aboba; Pat Calhoun (pacalhou)
> > Cc: aaa-wg at merit.edu; dime at ietf.org
> > Subject: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft
> > "ResourceManagement Extensions"
> >
> >
> > Hi all,
> >
> > may I raise your attention to the following draft submitted for
> > this meeting.
> >
> > Requirement for the addition of Auditing Functionality to Diameter
> > http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt
> >
> > Unfortunately, it did not yet show up.
> >
> > Ciao
> > Hannes
> 
> 
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
> 

_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime