Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 11 Nov 2002 10:02:44 -0800

I'm kind of confused

The charter talks about billing and accounting...
http://www.ietf.org/html.charters/ipfix-charter.html

"As such, there is a need in industry and the Internet research community
for IP devices such as routers to export flow information in a standard way
to external systems such as mediation systems, accounting/billing systems,
and network management systems to facilitate services such as Internet
research, measurement, accounting, and billing. "

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, November 11, 2002 12:48 PM
> To: Tal Givoly
> Cc: Juergen Quittek; [email-masked]
> Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> 
> 
> <ad>
> 
> > I feel strongly that "typical Internet reliability" is
> > insufficient to make this standard of value for a large set of
> > applications.
> 
> this is trivially true.  the question is whether such applications
> are, or should be, in the charter of this wg.  currently they are
> not.  if you wish to change that, then a change to the charter will
> be needed.  in this case, as it would seriously affect many
> parties, that will be a rather inclusive process and success is far
> from sure.
> 
> it would be nice if the wg could abjure mission creep.
> 
> </ad>
> 
> randy
> 
> 
> --
> 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/
>

---

From: "Tal Givoly" <[email-masked]>
Date: Mon, 11 Nov 2002 10:16:18 -0800

RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txtReinaldo,

I couldn't have put it better myself. Our involvement in this working group
is based on this charter, explicitly stating the support for billing and
accounting as possible applications of the protocol. If this is the case,
the requirements may need to be clarified, but the working group charter
already addresses the applications requiring a reliable protocol (at least
in part of its operational modes).

Tal
  -----Original Message-----
  From: Reinaldo Penno [mailto:[email-masked]]
  Sent: Monday, November 11, 2002 10:03 AM
  To: Randy Bush; Tal Givoly
  Cc: Juergen Quittek; [email-masked]
  Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt

  I'm kind of confused

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 Nov 2002 10:43:45 -0800

> The charter talks about billing and accounting...

yup.  use of the current style stuff to do those kinds of things is
reasonable.  bending the current stuff in order to boil the ocean
can be done in experimental drafts.  but the primary goal of this
wg is to reconcile some _current_ inter-vendor incompatibilities,
fix congestion control, etc.

perhaps we should have two wgs, ipwork and ipfix?

randy

--
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/

---

From: [email-masked]
Date: Mon, 11 Nov 2002 14:34:27 -0500

> fix congestion control, etc.

This thread started with a question on reliability...

	> Somehow, the requirements discussion suffers from a split:
	> There are requirements resulting from the intention of
	> standardzing a highly reliable metering standard for precise
	> accounting (and billing). Differing from these are requirements
	> for a simpler metering standard more oriented at what I would
	> call "typical Internet reliability".
	
	<ad> the original goal, which the iesg thinks was chartered, is the
	latter.  </ad>

To the charter once again...

	"o Ensure that the flow export system is reliable in that it will 
	minimize the likelihood of flow data being lost due to resource 
	constraints in the exporter or receiver and to accurately report 
	such loss if it occurs. "

I see mention of reliability but nothing about to what level. The
guiding
principal has been to try and standardize what is "out there" today.
Right now
we have Netflow with none, LFAP with a reliable transport and CRANE
with application level (not an exhaustive list, just the ones that come
to mind).

It would seem that coming to agreement on reliability is within the
charter.

Paul

---

From: Sebastian Zander <[email-masked]>
Date: Tue, 12 Nov 2002 10:59:46 +0100

> 	<ad> the original goal, which the iesg thinks was chartered, is the

Maybe someone can explain to me what "typical Internet reliability" is?

> It would seem that coming to agreement on reliability is within the

Paul, you are completly right. We should not try to boil the ocean but we
should boil enough water to make nice coffee for everyone. Or are we trying
to make coffee with cold water? :-)

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
FhI FOKUS / Global Networking (GloNe)    Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fhg.de/usr/sebastian.zander

---

From: "Peter Ludemann" <[email-masked]>
Date: Tue, 12 Nov 2002 19:28:59 -0800

Sebastian Zander wrote Tuesday, November 12, 2002 2:00 AM:

> should boil enough water to make nice coffee for everyone. Or are
> we trying to make coffee with cold water? :-)

I have a friend who does make coffee with cold water. It takes overnight
"soaking" of the coffee, though.

Seriously, I was hoping to convince people that a minimal conforming
implementation of a protocol with template negotiation and application
reliability is only a little more difficult to implement than the much less
useful protocols which don't have these features. (And I've even described
how to remove reliability for those who don't need/want it.)

[If my explanations are incomprehensible, please send me a private note with
a hint about what needs re-explaining and I'll do a rewrite.]

So, I don't think we need to boil the ocean but it is worthwhile to start
with fresh cold water, clean equipment and decent beans because for about
the same amount of effort, these give much better coffee.

And then we can turn our focus to the real stuff: what data are exported (I
foresee many opinions on customer use cases).

- peter

---

From: [email-masked]
Date: Wed, 13 Nov 2002 10:35:10 -0500

I'm left wondering what level of reliability is in scope?

It seems we a few people that agree a highly reliable 
protocol is out of scope and several agreeing it is in 
scope. Since one person from the former was wearing an AD 
hat I'm left still uncertain of the outcome.

Is high reliability in scope or out of scope. If out
of scope, to what level is in scope?

	1. Transport level reliability
	2. Redundancy reliability (e.g. sending all data 
	   to multiple collectors or multicasting)
	3. Failover (i.e. detecting a collector is 
	   down and switching to another)
	4. Congestion awareness only (i.e. send and forget)
	
What level of reliability is in scope?

Paul

---

From: Benoit Claise <[email-masked]>
Date: Fri, 15 Nov 2002 14:22:13 +0100

Paul,

Taking into account all the feedback sent so far to the mailing list

>	4. Congestion awareness only (i.e. send and forget)
Maybe we can add some more options. Let me also attempt to classify them.

	1. Congestion awareness only (i.e. send and forget)
        2. Receiver detection of IPFIX message loss
	3. Redundancy reliability (e.g. sending all data
	   to multiple collectors or multicasting)
	4. exporter detection of message loss caused by a broken link to collector
	5. Failover (i.e. detecting a collector is
	   down and switching to another)
        6. exporter detection of message loss caused by application level ACK not received
	7. Transport level reliability

1. and 2. are the minimum for IPFIX. 
   Taken into account by the req-07 as MUST(section 6.3.1 and section 6.3.2)

3. an easy solution.
   Taken into account by the req-07 as a MAY (section 8.3)

4. Taken into account by the req-07 as a SHOULD (section 6.3.2)

5. Taken into account by the req-07 as a MAY (section 6.3.2)

IMHO, this is as far as we should go in IPFIX.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Nov 2002 05:28:31 +0100

Dear all,

One clarification about the transport protocol that will be used NetFlow 
version 9, as UDP is not congestion aware.
Let me also stress that NetFlow version 9 has been designed to be 
transport protocol independent!

Cisco's official position is:
Reliable & congestion aware transport for NetFlow v9 is on the roadmap 
for Cisco IOS.  Cisco is currently studying various transport mechanisms 
including SCTP; if determined that SCTP is the best solution to satify 
this requirement, it will soon be implemented. 

http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
If you feel appropriate, the evaluation team should  update the section 
5.3 on data transfer accordingly (maybe U for upcoming compliance for 
example,)

5.3 Data Transfer  (6.3) 
    
5.3.1 Congestion Awareness  (6.3.1) 

LFAP: T     CRANE: T     IPDR: T     NetFlow: E     Diameter: T
                                       
5.3.2 Reliability  (6.3.2) 

LFAP: T     CRANE: T     IPDR: T     NetFlow: P     Diameter: T

     -E  Extension required for total compliance: The protocol is 
         prepared to be extended and it is possible to extend it in a 
         way that it meets the requirement. This grade is only 
         applicable to protocols that are explicitly open to externally 
         defined extensions, such as SNMP is extended by MIB modules or 
         DIAMETER is extended by application modules. It is not 
         applicable to protocols, where the protocol specification   
         itself needs to be extended in order to comply with the     
         requirement. 
    
     -P  Partial compliance: The requirement is met partially by the 
         protocol specification. 
    
     -U  Upcoming compliance: The requirement is not met or met 
          partially by the protocol specification, but there is a 
          concrete plan for an upcoming version of the protocol. 

Regards, Benoit.

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Nov 2002 22:22:20 -0800

<ad hat on>

> Cisco's official position is:

this is EXCEEDINGLY INAPPROPRIATE for an IETF mailing list.

randy

---

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Nov 2002 16:56:49 +0100

Dear all,

I just wanted to adjust a section in 
http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
Because I was seing the evaluation team not using the Upcoming 
Compliance status, even if I put it in my draft 
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt

    3.5.3.1 Congestion Awareness (6.3.1)
    Upcoming Compliance with SCTP.

Part of the IPFIX evaluation process, we are asked to evaluate our 
protocol against the IPFIX requirements.
We were even asked to say what we had in mind to make it more compliant 
(roadmap?). At least, this is the way I understood it.

Regarding future directions, I was thinking an official statement was 
appropriate.
Sorry if I offended anybody.

Now, maybe the question is about the Upcoming Compliance.
If this is not used by the evaluation team, maybe it should be removed 
from the evaluation process?

Regards, Benoit.