Subject: RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 6 Feb 2002 13:58:31 -0800

Hello,

I just read this QoS doc, which BTW is very nice, but I wonder whether this
is in-scope. I mean, how exactly you are going to perform QoS monitoring
depend in so many factors...applications, networks, etc. It should be
totally up to the implementation and indirectly who is doing the monitoring.

Maybe a different draft suggesting recommendations on QoS measurement
process for IPfix. Any thoughts?

regards,

Reinaldo

:-----Original Message-----
:From: Tanja Zseby [mailto:[email-masked]]
:Sent: Wednesday, February 06, 2002 3:30 AM
:To: K.C. Norseth
:Cc: [email-masked]
:Subject: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring
:
:
:Hi K.C.,
:
:attached you can find my contributions to the architecture document.
:
:- The first text contains some first thoughts on how IPFIX and 
:AAA could 
:communicate.
:
:- The second text contains considerations on how IPFIX can be used for 
:QoS monitoring. Maybe this can also go into the architecture document 
: (Ram Gopal for instance had a section on "some applications 
:for IPFIX" 
:in his text). Or do you think this should be put into a 
:separate document ?
:
:Regards
:Tanja
:
:-- 
:Dipl.-Ing. Tanja Zseby			    	      	
:FhI FOKUS/Global Networking			Email: 
:[email-masked]	
:Kaiserin-Augusta-Allee 31				Phone: 
:+49-30-3463-7153
:D-10589 Berlin, Germany				Fax:   
:+49-30-3463-8153
:---------------------------------------------------------------
:----------------------- 
:"Living on earth is expensive but it includes a free trip 
:around the sun." (Anonymous)
:---------------------------------------------------------------
:-----------------------
:
:

---

From: Tanja Zseby <[email-masked]>
Date: Thu, 07 Feb 2002 09:54:41 +0100

Hi Ram,

[email-masked] wrote:

>Hello Tanja,
>
>We are combining different sections from Kevin and you and forwarding to K.C. It will easy his compilation process.
>
O.K., thanks for this.

>
>WE are taking AAA scenario 1 and 2 and not 3. 3rd scenrio is not applicable to IPFIX.
>
I also see problems with realizing the 3rd scenario. Nevertheless, 
DIAMETER still is one candidate for the IPFIX protocol. That means there 
there has to be an evaluation (as for all the other candidates) with 
regard to the requirements first, before we can say whether this is 
applicable or not to IPFIX. (and that is mainly what I wrote in this 
section).

>
>Regarding Qos Monitoring we cannot do active measurement,rrt using flow unless the observation 
>point is the source of data. These belongs to IPPM and  beyond scope of IPFIX. 
>
As described in the text, QoS Monitoring is only passive measurement. 
All the described measurement techniques are passive. The RTT monitoring 
is based on existing traffic in the network. QoS Monitoring is one of 
the target applications for IPFIX. Therefore I think it is relevant for 
IPFIX. Maybe also for IPPM. Maybe we can check this with the IPPM group 
? I thought that it would fit into your text into the section "some 
applications for IPFIX" because there you mention IPFIX applications 
like accounting, intrusion detection, traffic engineering, but there is 
no section on QoS Monitoring. If it doesnt fit in there, it is o.k. for 
me to put it in a separate document.

>
>Sampling of Qos is for PSAM working group. 
>
Sampling is in our charter and is an optional feature for the IPFIX 
protocol from the requirements document. As far as I know there is no 
official psamp group until now (BOF planned for March ?) and the 
separation between IPFIX and psamp still  needs some clarification.

Regards
Tanja

>
>We will add your content and merge all the 4 documents into the one. IF you want to submit as a separate document let me know we will delete the sections.
>
> 
>Regards
>RAmg
> 
>
>>-----Original Message-----
>>From: ext Tanja Zseby [mailto:[email-masked]]
>>Sent: Wednesday, February 06, 2002 6:30 AM
>>To: K.C. Norseth
>>Cc: [email-masked]
>>Subject: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring
>>
>>
>>Hi K.C.,
>>
>>attached you can find my contributions to the architecture document.
>>
>>- The first text contains some first thoughts on how IPFIX and 
>>AAA could 
>>communicate.
>>
>>- The second text contains considerations on how IPFIX can be used for 
>>QoS monitoring. Maybe this can also go into the architecture document 
>>(Ram Gopal for instance had a section on "some applications 
>>for IPFIX" 
>>in his text). Or do you think this should be put into a 
>>separate document ?
>>
>>Regards
>>Tanja
>>
>>-- 
>>Dipl.-Ing. Tanja Zseby			    	      	
>>FhI FOKUS/Global Networking			Email: 
>>[email-masked]	
>>Kaiserin-Augusta-Allee 31				Phone: 
>>+49-30-3463-7153
>>D-10589 Berlin, Germany				Fax:   
>>+49-30-3463-8153
>>---------------------------------------------------------------
>>----------------------- 
>>"Living on earth is expensive but it includes a free trip 
>>around the sun." (Anonymous)
>>---------------------------------------------------------------
>>-----------------------
>>
>>
>

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: [email-masked]	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

---

From: "Siddiqui, Anwar A (Anwar)" <[email-masked]>
Date: Thu, 7 Feb 2002 09:23:14 -0500

Hello,
 
There are couple of issues with IPFIX and QOS Monitoring. 
 
1. There is RMON WG that is doing some work on QOS Monitoring. 
There are some standard tarck work in this space like SMON, RMON,
Application 
Performance Measurement (APM),  Transport Performance Measurement (TPM),

Synthetic Source Measurement (SSPM) etc. are a few solutions that
resdides in this space.
There is also a proposed darft for Realtime Application QOS Monitoring
(RAQMON) 
in RMON WG presented during last 2 IETF sessions. This draft has 
    --> a MIB definition for storage of data and 
    --> A protocol interface between the end devices to report QOS
parameters from an IP end device
to a report collector. 
 
It was raised in that WG during RAQMON presentation whether IPFIX can be
leveraged 
as a "light weight" protocol such that the IP end devices can use that
to report data
to report collector? 
 
Is this within the charter of IPFIX WG? When IPFIX was chartered, it was
focused towards
billing and reliable transport resquirements were heavy. However this
could be my misunderstanding too.
Can some one plese comment on that. 
 
Here is a copy of the RAQMON draft that we are working from. 
http://search.ietf.org/internet-drafts/draft-siddiqui-rmonmib-raqmon-mib
-00.txt
 
BTW there is also IPPM WG deciding on various methodologies of QOS
mesaurements.
 
Anwar

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 4:59 PM
To: Tanja Zseby; K.C. Norseth
Cc: [email-masked]
Subject: RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring

Hello, 

I just read this QoS doc, which BTW is very nice, but I wonder whether
this is in-scope. I mean, how exactly you are going to perform QoS
monitoring depend in so many factors...applications, networks, etc. It
should be totally up to the implementation and indirectly who is doing
the monitoring.

regards, 

Reinaldo 

:From: Tanja Zseby [ mailto:[email-masked]]

---

From: <[email-masked]>
Date: Mon, 11 Feb 2002 06:23:35 -0500

Its good then we can move the contents to last section ( may be ) as applicability.
Regards
Ramg

>From: ext Juergen Quittek [mailto:[email-masked]]
>Sent: Monday, February 11, 2002 6:23 AM
>To: Gopal Ram (NRC/Boston); [email-masked]
>Cc: [email-masked]; [email-masked]
>--On 11 February 2002 06:15 -0500 [email-masked] wrote:
>> As per charter we have only two deliverables. This is the
>> main reason we have to put it architecture.
>> Regards
>> Ramg
>
>I would be fine with having a separate section in the architecture
>RFC titled "applicability statements" or similarly.
>
>However, if you refer to the charter, then please read the last
>goal stated there:
>
>    "May 02 - Submit IPFX-ARCHITECTURE to IESG for publication,
>     Proposed Standard RFC (also need an Applicability Statement RFC)"
>
>Cheers,
>
>    Juergen
>-- 
>Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
>NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
>Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>
>
>>
>>> From: ext [email-masked] [mailto:[email-masked]]
>>> Sent: Saturday, February 09, 2002 1:24 AM
>>> To: Tanja Zseby
>>> Cc: Ganesh Sadasivan; [email-masked]; 
>[email-masked]
>>> Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring
>>>
>>>
>>> Hi Tanja,
>>>
>>> I agree with your statement. The discussion of interaction with AAA
>>> should not be part of the architecture document. So, let's take it
>>> out of it.
>>>
>>> Also I agree that this might fit very well into an applicability
>>> document. Why don't you just start editing one based on your text.
>>>
>>> Best wishes,
>>>
>>>    Juergen
>>> --
>>> Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
>>> NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
>>> Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>>>
>>>
>>> Tanja Zseby <[email-masked]> wrote:
>>>
>>>> Hi Ganesh
>>>>
>>>> I agree, that different applications can be consumer of IPFIX data.
>>>> Nevertheless, AAA defines a whole architecture for accounting and
>>>> itself provides input to accounting and billing
>>> applications. Therefore
>>>>
>>>> I think we need to show how IPFIX and AAA can work 
>together. I agree
>>>> that it is not the task of IPFIX to define the interfaces.
>>> And maybe you
>>>> are right, and the architecture document is not the rigtht 
>place for
>>>> this. If Nevil writes something on relations to RTFM we could put
>>>> together a document on relations between IPFIX and other
>>> WGs/frameworks.
>>>>
>>>> Or really start a applicability document with sections for
>>> the target
>>>> applications mentioned in the requirements draft.
>>>>
>>> [...]
>>>
>>> --
>>> Help        mailto:[email-masked] and say "help"
>>> in message body
>>> Unsubscribe mailto:[email-masked] and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>
>
>
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/