Subject: RE: [Dime] Update on Diameter Auditing

From: "Ulf Bodin" <[email-masked]>
Date: Mon, 6 Aug 2007 14:04:41 +0200

Replies below ([Ulf1:..]). 
BR Ulf 

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: den 30 juli 2007 01:33
To: Ulf Bodin
Cc: [email-masked]
Subject: RE: [Dime] Update on Diameter Auditing 

Ulf Bodin <mailto:[email-masked]> allegedly scribbled on Sunday,
July 29, 2007 1:22 AM:

> All,
> 
> As requested I'm giving a brief update on the Diameter Auditing work 
> at the list (basically the update I gave verbally on Friday's WG
> meeting):  
> 
> 
> There are two individual drafts on the topic; the Diameter Auditing 
> requirements draft, AR (draft-bodin-dime-auditing-reqs-02) and the 
> State recovery draft, SR (draft-asveren-dime-state-recovery-01). AR 
> gives high level requirements for Diameter auditing and contains 
> previous work done by Pat Calhoun on defining commads and AVPs for 
> auditing.

This draft is largely indecipherable.  Although there may be
requirements in there, I can't find them and there seems to be no actual
description of the problem it's trying to solve.  My _guess_ is that for
some unknown reason you are trying to use the network as a state
repository so that it can recover state after a failure.  Is that right?
If so, why is this scheme better than, say, NVRAM?

[Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is to
capture needs for auditing in a wider sense the usage that triggered us
writing the draft is the ETSI TISPAN RACS/ITU-T RACF, which is an entity
keeping track of resource reservations for IP-based networks. The states
kept in such entity is mot necesserily present in any network device. At
failover from active to standby NVRAM does not help. I.e. non-volatile
local storage does not help when failing over between physically
separted entities. draft-asveren-dime-state-recovery-01 explores the
problem of state recovery further and may do a better job in actually
defining requirements for state recovery/auditing.] 

> SR provides an analyze of what protocol assisted mechanisms
> can be helfull in performing state recovery.      
> 
> Some mails have been exchanged in June studying which commands and 
> AVPs either defined in Calhouns original work or that exists in other 
> Dimeter specificaitons that could be used or enhanced for protocol 
> assisted state recovery (i.e. auditing).

Maybe part of the problem is the (mis)use of the word auditing.
Thinking that I was ignorant I made a rather extensive search of
dictionaries and was unable to find a definition of the word "auditing"
that remotely resembled "protocol assisted (sic) state recovery".

[Ulf1: I can agree that the word auditing can be misleading. State
recovery may indeed better indicate what this is all about.]

> My intention is to proceed
> that work and before the next IETF meeting collect what then have been

> done on the mailing list into a draft presenting desired extensions to

> Dimaeter for protocol assisted state recovery. Based on that work it'd

> in my view make sence considering taking on Diameter
> protocol assisted state recovery as a WG work item.    

Why?

[Ulf1: Earlier this year we debated this very valid question on the
mailing list. My and some others oppinion are that mechanisms for state
recovery (I'll use that term instead of auditing) should be defined by
the IETF for usage by various Diameter applications e.g. such as those
defined by ETSI TISPAN, ITU-T, 3GPP, etc. instead of relying on these
SDOs defining separate mechanisms potentially for each individual
application. By that we can avoid different mechanisms being used for
basically the same thing, which I fear easily can result in less than
optimal solutions.]
   
> 
> BR Ulf
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime

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

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 6 Aug 2007 09:53:58 -0700

Ulf Bodin <mailto:[email-masked]> allegedly scribbled on Monday,
August 06, 2007 5:05 AM:

...

> 
> [Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is
> to capture needs for auditing in a wider sense the usage that
> triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF,

Where can I get a copy of the document defining this entity?

> which is an entity keeping track of resource reservations for
> IP-based networks. The states kept in such entity is mot necessarily
> present in any network device. At failover from active to standby
> NVRAM does not help. I.e. non-volatile local storage does not help
> when failing over between physically separted entities.
> draft-asveren-dime-state-recovery-01 explores the problem of state
> recovery further and may do a better job in actually defining
> requirements for state recovery/auditing.]  

I'd actually prefer to see a document saying why this is actually needed
in a real network, rather than one that assumes its necessity as a
starting point.  BTW, it was the lack of that clear necessity that led
to the demise of the original resource management work, IIRC.
        
...

---

From: "Ulf Bodin" <[email-masked]>
Date: Tue, 7 Aug 2007 13:16:49 +0200

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: den 6 augusti 2007 18:54
To: Ulf Bodin
Cc: [email-masked]
Subject: RE: [Dime] Update on Diameter Auditing 

...

[Ulf2: Unfortunately access to specifications published by ETSI and ITU
requires membership or purchase of each particular publication. The
documents can most likely be shared using a liason statement issued by
ETSI and/or ITU in case we need those specifciations for reference (in
particular for them working for an organization not being member of
those SDOs). However, the MSF (Multi-Service Forum) has published a
document giving an overview of this kind of entity that I believe could
be sufficient
(http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-005-FINAL.pdf).]

> which is an entity keeping track of resource reservations for IP-based

> networks. The states kept in such entity is mot necessarily present in

> any network device. At failover from active to standby NVRAM does not 
> help. I.e. non-volatile local storage does not help when failing over 
> between physically separted entities.

[Ulf2: Yes, that's my understanding as well for why the work was demised
a couple of years back. However, given the appearance of RACS/RACF in
ETSI TISPAN/ITU-T and the widespread usage of Diameter in 3GPP/3GPP2/MSF
etc. I think this shows that that mechanisms for state recovery is
actually needed for products now being developed for usage in real
networks. 

And, in TISPAN, H.248 was back in 2005 actually considered as an
alternative to Diameter to be used for one of the interfaces to RACS
partly due to its auditing capabilities that also can be used for state
recovery (H.248 is used in the published architecture, but for a
different interface).] 

...

---

From: Tina TSOU <[email-masked]>
Date: Tue, 07 Aug 2007 19:39:50 +0800

Hi,
In ITU-T, it is free with your TIES account now. Cisco is the sector member 
of ITU-T, so Glen can apply a TIES account.
Architecture:
      Y.2111
     Resource and admission control functions in Next Generation Networks

      Procedure and Protocol:

      Q.3301.1
     Resource control protocol - Protocol at the Rs interface   (with simple 
audit inside, to check whether the session indicated by the Session-Id in 
the RAR message is active, not including the state recovery)

      Q.3302.1
     Resource control protocol - Protocol at the Rp interface

In ETSI, it is also free with your ETSI account. Cisco is the member of 
ETSI, so Glen can apply a ETSI account.
Architecture:
http://pda.etsi.org/pda/home.asp?wki_id=m5ClL_vIFdCECIEF7HHwR

B. R.
Tina

----- Original Message ----- 
From: "Ulf Bodin" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 07, 2007 7:16 PM
Subject: RE: [Dime] Update on Diameter Auditing

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]]
Sent: den 6 augusti 2007 18:54
To: Ulf Bodin
Cc: [email-masked]
Subject: RE: [Dime] Update on Diameter Auditing

...

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 7 Aug 2007 13:59:44 +0200

Actually one does not even need a TIES account. ITU-T is making its
specifications available for free on experimental basis for now as I
understand at http://www.itu.int/rec/T-REC/e. 

Dan

> From: Tina TSOU [mailto:[email-masked]] 
> Sent: Tuesday, August 07, 2007 2:40 PM
> To: [email-masked]; Ulf Bodin
> Subject: Re: [Dime] Update on Diameter Auditing
> 
> Hi,
> In ITU-T, it is free with your TIES account now. Cisco is the 
> sector member of ITU-T, so Glen can apply a TIES account.
> Architecture:
>       Y.2111
> audit inside, to check whether the session indicated by the 
> Session-Id in the RAR message is active, not including the 
> state recovery)
> 
>       Q.3302.1
> In ETSI, it is also free with your ETSI account. Cisco is the 
> member of ETSI, so Glen can apply a ETSI account.
> Architecture:

---

From: "Ulf Bodin" <[email-masked]>
Date: Tue, 7 Aug 2007 14:29:13 +0200

Great. Thank you Tina and Dan for pointing this out. IMO having open
access is to the benefit of everyone including ETSI and ITU. To be
honest I've never understood completely why restricting access (i.e.
must be another way to have organizations pay to run an SDO). 

Rgs Ulf  

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: den 7 augusti 2007 14:00
To: Tina TSOU; [email-masked]; Ulf Bodin
Subject: RE: [Dime] Update on Diameter Auditing

Dan

> In ITU-T, it is free with your TIES account now. Cisco is the sector 
> member of ITU-T, so Glen can apply a TIES account.
> Architecture:
>       Y.2111
> audit inside, to check whether the session indicated by the Session-Id

> in the RAR message is active, not including the state recovery)
> 
>       Q.3302.1
> In ETSI, it is also free with your ETSI account. Cisco is the member 
> of ETSI, so Glen can apply a ETSI account.
> Architecture:

> [Ulf2: Unfortunately access to specifications published by ETSI and 
> ITU requires membership or purchase of each particular publication. 
> The documents can most likely be shared using a liason statement 
> issued by ETSI and/or ITU in case we need those specifciations for 
> reference (in particular for them working for an organization not 
> being member of those SDOs). However, the MSF (Multi-Service Forum) 
> has published a document giving an overview of this kind of entity 
> that I believe could be sufficient 
> I'd actually prefer to see a document saying why this is actually 
> needed in a real network, rather than one that assumes its necessity 
> as a starting point.  BTW, it was the lack of that clear necessity 
> that led to the demise of the original resource management work, IIRC.
> 
> [Ulf2: Yes, that's my understanding as well for why the work was 
> demised a couple of years back. However, given the appearance of 
> RACS/RACF in ETSI TISPAN/ITU-T and the widespread usage of Diameter in

> 3GPP/3GPP2/MSF etc. I think this shows that that mechanisms for state 
> recovery is actually needed for products now being developed for usage

> in real networks.
> partly due to its auditing capabilities that also can be used for 
> state recovery (H.248 is used in the published architecture, but for a

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 7 Aug 2007 11:35:50 -0700

Ulf Bodin <mailto:[email-masked]> allegedly scribbled on Tuesday,
August 07, 2007 4:17 AM:

...

...

> RACS/RACF in ETSI TISPAN/ITU-T and the widespread usage of Diameter
> in 3GPP/3GPP2/MSF etc. I think this shows that that mechanisms for
> state recovery is actually needed for products now being developed
> for usage in real networks.   

Except that a) it seems not possible for us to evaluate the basis of
this work (let alone the work itself) and b) I, at least, hold a
somewhat less sanguine opinion of standards bodies: just because some
(professional or amateur) standards folks have invented something
doesn't mean that it's necessary or even useful.

...

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 7 Aug 2007 11:35:51 -0700

Tina TSOU <mailto:[email-masked]> allegedly scribbled on Tuesday,
August 07, 2007 4:40 AM:

> Session-Id in the RAR message is active, not including the state
> recovery)  
> 
>       Q.3302.1

Thanks for the data, Tina, but the issue isn't really whether I or other
Cisco employees are able to access the documents but whether the IETF
Community at large has such access.  We can't be expected to standardize
something based upon documents we can't see.

...

---

From: Tom Taylor <[email-masked]>
Date: Tue, 07 Aug 2007 15:29:51 -0400

OK, let's say this one more time.  ITU-T documents are available for free to 
everyone, not just Cisco, at http://www.itu.int/ITU-T/publications/recs.html.

ETSI published specifications are available for free to everyone, not just 
Cisco, at http://pda.etsi.org/pda/queryform.asp.  ETSI work in progress is 
available free to everyone, not just Cisco, at 
http://portal.etsi.org/docbox/TISPAN/Open/NGN_LATEST_DRAFTS/

I can dig out the relevant ETSI publication numbers, but people who are working 
with this stuff regularly may have them readily to hand.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 7 Aug 2007 13:40:00 -0700

Tom Taylor <mailto:[email-masked]> allegedly scribbled on
Tuesday, August 07, 2007 12:30 PM:

> OK, let's say this one more time.  ITU-T documents are available for
> free to everyone, not just Cisco, at
> http://www.itu.int/ITU-T/publications/recs.html.  
> 
> ETSI published specifications are available for free to everyone, not
> just Cisco, at http://pda.etsi.org/pda/queryform.asp.  ETSI work in
> progress is available free to everyone, not just Cisco, at

OK, let's say _this_ one more time: this is neither ETSI nor ITU-T.  I
don't think that a simple I-D cogently describing the problem to be
solved is too much to ask; if it is, then maybe there _is_ no problem.
Not that I'm opposed to full employment for protocol designers but it
seems to me that the above referenced organizations (among many others)
provide ample opportunity: we don't need to help them out here.
 
...

---

From: "Ulf Bodin" <[email-masked]>
Date: Wed, 8 Aug 2007 08:09:56 +0200

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: den 7 augusti 2007 20:36
To: Ulf Bodin
Cc: [email-masked]
Subject: RE: [Dime] Update on Diameter Auditing 

...

...

> recovery is actually needed for products now being developed

[Ulf3: Skipping a) to reply to it in a separate mail I must say b) makes
me somewhat confused. I can agree to that standards not always become
widely used in reality depending on market needs, kind of solution
preferred by ccustomer etc. However, IMHO standards should at least be
seen as potetially useful and part of the game in evolving businesses
including vendors and operators/network providers/ISPs/etc. Waiting for
things to be used in real networks before starting standardizing may in
my view be beneficial to larger vendors having the power to get new
solutions and protocol mechanisms in operation with customers, while
smaller vendors and operators better rely on standards (in progress and
published). Maybe I'm missing the point here (e.g. that the IETF only
aims at standardizing things alrady in use and thereby proved useful).] 

...

---

From: "Ulf Bodin" <[email-masked]>
Date: Wed, 8 Aug 2007 10:13:54 +0200

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: den 7 augusti 2007 22:40
To: Tom Taylor
Cc: Tina TSOU; Ulf Bodin; [email-masked]
Subject: RE: [Dime] Update on Diameter Auditing

[Ulf: What we have are two drafts; draft-bodin-dime-auditing-reqs-02 and
draft-asveren-dime-state-recovery-01. While the first draft provides a
somewhat more general description of requirements that I agree may not
be sufficient to derive protocol mechanisms from, the seconds draft come
in my view closer to providing a base for such work.]
 
...