Subject: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft "Resource Management Extensions"

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 21 Jun 2006 17:32:59 +0200

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

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Bernard Aboba
> Gesendet: Mittwoch, 21. Juni 2006 16:24
> An: Pat Calhoun (pacalhou)
> Cc: MORAND Lionel RD-CORE-ISS; [email-masked]
> Betreff: [AAA-WG]: RE: Conclusions on the draft "Resource 
> Management Extensions"
> 
> As Pat said, the major priority of the AAA WG was completing 
> work on the 
> Diameter Base protocol and applications.  I actually don't 
> recall whether 
> the WG made a judgement on the Resource Management draft; it 
> just wasn't 
> one of the top priorities. 
> 
> I will say that the Diameter architecture provides a much more sound 
> base for resource management than RADIUS does.  Most of the resource 
> management implementations I have seen on RADIUS need to 
> incorporate other 
> information sources for validation, in order to deal with 
> potential losses 
> of RADIUS Accounting packets.  Since Diameter runs over reliable 
> transport, it should not have to do this. 
> 
> On Wed, 21 Jun 2006, Pat Calhoun (pacalhou) wrote:
> 
> > I'll let Bernard speak for the WG, but at the time the WG 
> had many other
> > priorities, and resource management was not one of them. However, I
> > haven't had the opportunity to participate in the AAA WG 
> for some time,
> > so I'm not sure if this could be an opportune time to 
> re-introduce it.
> >  
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> > 
> >  
> > 
> > 
> > ________________________________
> > 
> > 	From: MORAND Lionel RD-CORE-ISS
> > [mailto:[email-masked]] 
> > 	Sent: Wednesday, June 21, 2006 7:07 AM
> > 	To: Bernard Aboba; Pat Calhoun (pacalhou)
> > 	Subject: Conclusions on the draft "Resource Management
> > Extensions"
> > 	
> > 	
> > 
> > 	Hi, 
> > 	I would like to know what were the conclusions on the following
> > draft initiated by Pat: draft-calhoun-diameter-res-mgmt-08.txt.
> > 
> (http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter
> -res-mgmt-
> > 08.txt
> > 
> <http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter
> -res-mgmt-
> > 08.txt> )
> > 
> > 	Some folks from TISPAN are initiating a document based on this
> > draft to perform resource management after failover, proposing to
> > enhance the Diameter base protocol with dedicated commands. 
> I'm pretty
> > sure that the previous comments/concerns about such enhancements are
> > still valid.
> > 
> > 	BR, 
> > 	Lionel 
> > 
> > 
> > 
> 

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 21 Jun 2006 12:13:15 -0400

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.

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:[email-masked]]
> Sent: Wednesday, June 21, 2006 11:33 AM
> Cc: [email-masked]; [email-masked]
> Subject: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft
> "ResourceManagement Extensions"
>
>
> Hi all,
>

---

From: Tony Zhang <[email-masked]>
Date: Sat, 24 Jun 2006 11:15:19 +0800

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, June 22, 2006 12:13 AM
Subject: RE: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft"ResourceManagement Extensions"

> 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 26 Jun 2006 14:52:35 -0400

One more question about this draft:

AFAICS, there are actually two different issues (they are related but not
the same):
a)Preventing session leaking
Making sure that after a node fails, other nodes do not continue keeping
state for the lost sessions.

b)Retrieving state information
After a node reboots, it retrieves its state data from another node.

When I first read draft-bodin-dime-auditing-reqs-00, I had the impression
that the main concern is a), based on the example scenarios described. OTOH,
draft-calhoun-diameter-res-mgmt-08 seem to deal with b).

So, what is the main issue a) or b)? If both, what are their priorities.

   Thanks,
   Tolga