Subject: [ipfix] IPFIX Design draft updates

From: "Norseth, KC" <[email-masked]>
Date: Fri, 15 Feb 2002 14:51:32 -0500

IPFIX People.

I have updated both the team architectural and data drafts.  The .txt
versions are enclosed.  If someone wants them in Word format. Let me know.
I am not worried at the moment of pagenation and 

Changes to the drafts:

Architecture:
*	Reordering sections and better integration of the sections from
Beniot and Ganesh's draft.  
*	Further definition of some areas.
*	Spelling and grammer 

Data:
*	Integrating sections Beniot and Ganesh's draft.  
*	Further definition of some areas.
*	Clarification of element types and how to define them.  Now I need
is the TC's to go along with each element.
*	Spelling and grammer 

If I have missed some updates to the draft, let me know.

If you have any questions, just ask.  Please give as many comments to the
group as possible over the weekend, where the "editorial review" board is
going to review everything on Monday.  

As recommended by Nevil, I will submit this as an individual draft,
submitted by the design group.  This way, reguardless of how the editoral
board combines /removes text, this will be recorded for Minneapolis so it
can be discussed as needed, just Benoit and Ganesh's  is.  It will also be
given an IPFIX team name, not IETF-IPFIX.

K.C.
 <<draft-ietf-ipfix-data-00.txt>>  <<draft-ietf-ipfix-architecture-00.txt>> 
K.C. Norseth
Firmware Engineering -  Routing 
Enterasys Networks
   Phone: 801.887.9823
   FAX:    801.972.5789 
   Email:   [email-masked]
   www:    http://www.enterasys.com <http://www.enterasys.com> 
 <<Norseth, KC.vcf>>

---

From: "Kevin Zhang" <[email-masked]>
Date: Fri, 15 Feb 2002 18:17:57 -0500

IPFIX Design draft updatesHi KC,

The architecture draft looks quite good to me, and I believe the addition
from Beniot and Ganesh's text really strengthened the document.

The entire section 5 of the data draft is very troublesome.  If I remember
correctly, at the conference call several weeks ago, we (including Cisco)
agreed that the Cisco draft dived into protocol too soon, and we should
complete the architecture and the data model documents before
assessing/selecting a protocol. The message formats definitely belong to a
protocol specification, not the data model draft.  I suggest to remove
entire section 5 from the data model draft.

If the group decides that the data model draft will specify messages passing
between IPFIX end-points, I suggest we include the formats from LFAF and
CRANE as they were proposed as candidate protocols just like Netflow.

Thanks,

Kevin

 -----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf Of
Norseth, KC
Sent: Friday, February 15, 2002 2:52 PM
To: [email-masked]'
Subject: [ipfix] IPFIX Design draft updates

  IPFIX People.

  Changes to the drafts:

  Architecture:

    a.. Reordering sections and better integration of the sections from
Beniot and Ganesh's draft.
    b.. Further definition of some areas.
    c.. Spelling and grammer

  Data:

    a.. Integrating sections Beniot and Ganesh's draft.
    b.. Further definition of some areas.
    c.. Clarification of element types and how to define them.  Now I need
is the TC's to go along with each element.
    d.. Spelling and grammer

  K.C.
  <<draft-ietf-ipfix-data-00.txt>> <<draft-ietf-ipfix-architecture-00.txt>>
  K.C. Norseth
  Firmware Engineering -  Routing
  Enterasys Networks
     Phone: 801.887.9823
     FAX:    801.972.5789
     Email:   [email-masked]
     www:    http://www.enterasys.com
  <<Norseth, KC.vcf>>

---

From: "K.C. Norseth" <[email-masked]>
Date: Fri, 15 Feb 2002 16:44:44 -0700

IPFIX Design draft updatesI have no problem with that.  The data draft needed something in layout more than a line saying we can consider LFAP,CRANE, or NetFlow, so I brought up the Cisco draft as a basis for starting..  The individual elements defined are much better using the other documents.  That has always been a weakness of NetFlow, defining the elements of the data where people didn't have to search for answers.

I wonder if you could give me the CRANE alternative to section 5, and Paul an LFAP alternative?  What I could do is put in 3 different section 5's in te data draft for people to see.  The team draft we submit can eaasily have 3 alternatives.

K.C.
  ----- Original Message ----- 
  From: Kevin Zhang 
  To: Norseth, KC ; [email-masked] 
  Sent: Friday, February 15, 2002 4:17 PM
  Subject: RE: [ipfix] IPFIX Design draft updates

  Hi KC,
   
  The architecture draft looks quite good to me, and I believe the addition from Beniot and Ganesh's text really strengthened the document. 
   
  The entire section 5 of the data draft is very troublesome.  If I remember correctly, at the conference call several weeks ago, we (including Cisco) agreed that the Cisco draft dived into protocol too soon, and we should complete the architecture and the data model documents before assessing/selecting a protocol. The message formats definitely belong to a protocol specification, not the data model draft.  I suggest to remove entire section 5 from the data model draft.  
   
  If the group decides that the data model draft will specify messages passing between IPFIX end-points, I suggest we include the formats from LFAF and CRANE as they were proposed as candidate protocols just like Netflow.  
   
  Thanks,
   
  Kevin

   
   -----Original Message-----
  From: majordomo listserver [mailto:[email-masked]]On Behalf Of Norseth, KC
  Sent: Friday, February 15, 2002 2:52 PM
  To: [email-masked]'
  Subject: [ipfix] IPFIX Design draft updates

    IPFIX People. 

    I have updated both the team architectural and data drafts.  The .txt versions are enclosed.  If someone wants them in Word format. Let me know.  I am not worried at the moment of pagenation and 

    Changes to the drafts: 

    Architecture: 

      a.. Reordering sections and better integration of the sections from Beniot and Ganesh's draft.  
      b.. Further definition of some areas. 
      c.. Spelling and grammer 

    Data: 

      a.. Integrating sections Beniot and Ganesh's draft.  
      b.. Further definition of some areas. 
      c.. Clarification of element types and how to define them.  Now I need is the TC's to go along with each element. 
      d.. Spelling and grammer 

    If you have any questions, just ask.  Please give as many comments to the group as possible over the weekend, where the "editorial review" board is going to review everything on Monday.  

    As recommended by Nevil, I will submit this as an individual draft, submitted by the design group.  This way, reguardless of how the editoral board combines /removes text, this will be recorded for Minneapolis so it can be discussed as needed, just Benoit and Ganesh's  is.  It will also be given an IPFIX team name, not IETF-IPFIX.

    K.C.

---

From: Peram Marimuthu <[email-masked]>
Date: Sat, 16 Feb 2002 08:06:04 -0800

Having 3 alternatives loses the meaning of standardization.

Peram

"K.C. Norseth" wrote:

> I have no problem with that.  The data draft needed something in layout more than a line
> saying we can consider LFAP,CRANE, or NetFlow, so I brought up the Cisco draft as a
> basis for starting..  The individual elements defined are much better using the other
> documents.  That has always been a weakness of NetFlow, defining the elements of the
> data where people didn't have to search for answers. I wonder if you could give me the
> CRANE alternative to section 5, and Paul an LFAP alternative?  What I could do is put in
> 3 different section 5's in te data draft for people to see.  The team draft we submit
> can eaasily have 3 alternatives. K.C.
>
>       Hi KC,The architecture draft looks quite good to me, and I believe the
>      addition from Beniot and Ganesh's text really strengthened the document. The
>      entire section 5 of the data draft is very troublesome.  If I remember
>      protocol specification, not the data model draft. I suggest to remove entire
>      section 5 from the data model draft. If the group decides that the data model
>      draft will specify messages passing between IPFIX end-points, I suggest we
>      include the formats from LFAF and CRANE as they were proposed as candidate
>      protocols just like Netflow. Thanks,Kevin-----Original Message-----
>           I have updated both the team architectural and data drafts.  The
>           .txt versions are enclosed.  If someone wants them in Word format.
>           Let me know.  I am not worried at the moment of pagenation and
>
>           Changes to the drafts:
>
>           Architecture:
>
>              * Clarification of element types and how to define them.  Now I
>                need is the TC's to go along with each element.
>              * Spelling and grammer
>
>           If you have any questions, just ask.  Please give as many comments
>           to the group as possible over the weekend, where the "editorial
>           review" board is going to review everything on Monday.
>
>           submitted by the design group.  This way, reguardless of how the
>           editoral board combines /removes text, this will be recorded for
>           Minneapolis so it can be discussed as needed, just Benoit and
>           Ganesh's  is.  It will also be given an IPFIX team name, not
>           IETF-IPFIX.
>
>           K.C.

---

From: "K.C. Norseth" <[email-masked]>
Date: Sat, 16 Feb 2002 13:43:07 -0700

Hi Peram,

At the moment, we have no standard.  We have flow accounting implementations in place already, NetFlow, CRANE, and LFAP are three of these.  They all have merits.  For us to say that NetFlow is the best without the concensus of the group is wrong.  What I am proposing is that we provide 3 alternatives for people to see and comment on.  These 3 alternatives will be narrowly focused (Just a section 5 equivalent definition) enough so that the overlapping information is removed, and they can focus on what is there.  From the concensus of the WG people, we can create SYNERGY from the 3 proposals and build our standard.  

In this first draft, there is no rule that says we have to have a polished protocol.  The Rough concensus of the IPFIX WG needs to be asked for.  I expect the first draft will be the most important to get our thoughts across.  After Minneapolis, we will have an emerging standard from these presented.

We do not not have to have 100% approval, althoug that would be our dream.  Remember, that for a standard to be accepted, we need rough concensus and running code.  Not one or the other, but both.

K.C.

  ----- Original Message ----- 
  From: Peram Marimuthu 
  To: K.C. Norseth 
  Cc: [email-masked] ; Norseth, KC ; [email-masked] 
  Sent: Saturday, February 16, 2002 9:06 AM
  Subject: Re: [ipfix] IPFIX Design draft updates

  "K.C. Norseth" wrote: 

    I have no problem with that.  The data draft needed something in layout more than a line saying we can consider LFAP,CRANE, or NetFlow, so I brought up the Cisco draft as a basis for starting..  The individual elements defined are much better using the other documents.  That has always been a weakness of NetFlow, defining the elements of the data where people didn't have to search for answers. I wonder if you could give me the CRANE alternative to section 5, and Paul an LFAP alternative?  What I could do is put in 3 different section 5's in te data draft for people to see.  The team draft we submit can eaasily have 3 alternatives. K.C. 
      ----- Original Message -----
      From: Kevin Zhang
      To: Norseth, KC ; [email-masked]
      Sent: Friday, February 15, 2002 4:17 PM
      Subject: RE: [ipfix] IPFIX Design draft updates
       Hi KC,The architecture draft looks quite good to me, and I believe the addition from Beniot and Ganesh's text really strengthened the document. The entire section 5 of the data draft is very troublesome.  If I remember correctly, at the conference call several weeks ago, we (including Cisco) agreed that the Cisco draft dived into protocol too soon, and we should complete the architecture and the data model documents before assessing/selecting a protocol. The message formats definitely belong to a protocol specification, not the data model draft. I suggest to remove entire section 5 from the data model draft. If the group decides that the data model draft will specify messages passing between IPFIX end-points, I suggest we include the formats from LFAF and CRANE as they were proposed as candidate protocols just like Netflow. Thanks,Kevin-----Original Message----- 
      From: majordomo listserver [mailto:[email-masked]]On Behalf Of Norseth, KC 
      Sent: Friday, February 15, 2002 2:52 PM 
      To: [email-masked]' 
      Subject: [ipfix] IPFIX Design draft updates 
        
        IPFIX People. 

        Changes to the drafts: 

        Architecture: 

        K.C.

---

From: Peram Marimuthu <[email-masked]>
Date: Sat, 16 Feb 2002 13:52:14 -0800

KC,

There are separate documents for everyone to look at and evaluate the merits
and short comings of each protocol. To say, IPfix offers a choice of 3 alternatives
is as good as not standardization at all. We need to take a suitable path which proposes
a middle ground with all the benefits.

Since Nevil has suggested an editorial team of 5, I would suggest that you discuss
Netflow, LFAP and Crane amongst yourselves and come out with a suitable proposal to
the IPfix mailing list. We can all discuss your suggestions at that point.

We need rough consensus, but we also need to make progress. Having 3 proposals on the
table will definitely make it slower at Minneapolis.

Peram

"K.C. Norseth" wrote:

>  Hi Peram, At the moment, we have no standard.  We have flow accounting implementations
> in place already, NetFlow, CRANE, and LFAP are three of these.  They all have merits.
> For us to say that NetFlow is the best without the concensus of the group is wrong.
> What I am proposing is that we provide 3 alternatives for people to see and comment on.
> These 3 alternatives will be narrowly focused (Just a section 5 equivalent definition)
> enough so that the overlapping information is removed, and they can focus on what is
> there.  From the concensus of the WG people, we can create SYNERGY from the 3 proposals
> and build our standard. In this first draft, there is no rule that says we have to have
> a polished protocol.  The Rough concensus of the IPFIX WG needs to be asked for.  I
> expect the first draft will be the most important to get our thoughts across.  After
> Minneapolis, we will have an emerging standard from these presented. We do not not have
> to have 100% approval, althoug that would be our dream.  Remember, that for a standard
> to be accepted, we need rough concensus and running code.  Not one or the other, but
> both. K.C.
>
>
>     > I have no problem with that.  The data draft needed something in layout more
>     > than a line saying we can consider LFAP,CRANE, or NetFlow, so I brought up
>     > the Cisco draft as a basis for starting..  The individual elements defined
>     > are much better using the other documents.  That has always been a weakness
>     > of NetFlow, defining the elements of the data where people didn't have to
>     > search for answers. I wonder if you could give me the CRANE alternative to
>     > section 5, and Paul an LFAP alternative?  What I could do is put in 3
>     > different section 5's in te data draft for people to see.  The team draft we
>     > submit can eaasily have 3 alternatives. K.C.
>     >
>     >      Hi KC,The architecture draft looks quite good to me, and I believe
>     >      the addition from Beniot and Ganesh's text really strengthened the
>     >      document. The entire section 5 of the data draft is very
>     >      troublesome.  If I remember correctly, at the conference call
>     >      several weeks ago, we (including Cisco) agreed that the Cisco
>     >      draft dived into protocol too soon, and we should complete the
>     >      architecture and the data model documents before
>     >      assessing/selecting a protocol. The message formats definitely
>     >      belong to a protocol specification, not the data model draft. I
>     >      suggest to remove entire section 5 from the data model draft. If
>     >      the group decides that the data model draft will specify messages
>     >      passing between IPFIX end-points, I suggest we include the formats
>     >      from LFAF and CRANE as they were proposed as candidate protocols
>     >      just like Netflow. Thanks,Kevin-----Original Message-----
>     >           I have updated both the team architectural and data
>     >           drafts.  The .txt versions are enclosed.  If someone
>     >           wants them in Word format. Let me know.  I am not
>     >           worried at the moment of pagenation and
>     >
>     >           Changes to the drafts:
>     >
>     >           Architecture:
>     >
>     >              * Reordering sections and better integration of the
>     >                sections from Beniot and Ganesh's draft.
>     >              * Clarification of element types and how to define
>     >                them.  Now I need is the TC's to go along with each
>     >                element.
>     >              * Spelling and grammer
>     >
>     >           If you have any questions, just ask.  Please give as
>     >           many comments to the group as possible over the weekend,
>     >           where the "editorial review" board is going to review
>     >           everything on Monday.
>     >
>     >           As recommended by Nevil, I will submit this as an
>     >           individual draft, submitted by the design group.  This
>     >           way, reguardless of how the editoral board combines
>     >           /removes text, this will be recorded for Minneapolis so
>     >           it can be discussed as needed, just Benoit and Ganesh's
>     >           is.  It will also be given an IPFIX team name, not
>     >           IETF-IPFIX.
>     >
>     >           K.C.

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Feb 2002 16:33:43 -0800

[ ad hat on ]

> To say, IPfix offers a choice of 3 alternatives is as good as not
> standardization at all.

from the wg charter:

  "This group will select a protocol ..."

note the use of the singular.  and note "select," not "invent."  and

   "Specific Goals 

    o Define the notion of a "standard IP flow." The flow definition
      will be a practical one, similar to those currently in use by
      existing non-standard flow information export protocols which have
      attempted to achieve similar goals but have not documented their
      flow defintion."

> We need to take a suitable path which proposes a middle ground with
> all the benefits.

if it has all the benefits, uses congestion-aware transport, is not
encumbered, ... it need not be a middle ground, just an effective one.

note also

   "Goals and Milestones:

    Feb 02  Submit IPFX-REQUIREMENTS to IESG for publication as an
	    Informational RFC
    Feb 02  Submit Internet-Draft on IP Flow Export Architecture
    Feb 02  Submit Internet-Draft on IP Flow Export Data Model"

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: "K.C. Norseth" <[email-masked]>
Date: Sat, 16 Feb 2002 15:52:09 -0700

Peram,

Comments inline.
  ----- Original Message ----- 
  From: Peram Marimuthu 
  To: K.C. Norseth 
  Cc: [email-masked] ; Norseth, KC ; [email-masked] 
  Sent: Saturday, February 16, 2002 2:52 PM
  Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design draft updates)

  KC, 

What I said is that there are three solutions out there right now.  From these three solutions, we have 2 choices:  1: Adopt one of these choices or 2: Build a standard from theses choices.  For the merits of both to be evaluated, it would be nice to see the differences side by side.   I never said that IPFIX would have at the end 3 different choices, just three for people to look at and decide from. What I propose on the design team draft is to have one section that defines each as concise as possible for people so it is easy to decide if we adopt one or another or combine.

The section of concern before my last change said that there were three possibilities.  They did not explain the pros and cons. This can help.

I am sure it will be discussed.  The editorial boards responsibility is to put together the first draft of IPFIX.  I dont think we will have enough consensus of the whole group to dictate only one alternative on the first draft.  If we have three alternatives clearly defined on the first draft, and helps the WG make a decision quickly, so what?  

Progress is when we look at all sides for a solution.  It costs more when only one solution is provided and it ends up not  being the best one.  History is clear in that.

K.C.

  Peram 

  "K.C. Norseth" wrote: 

     Hi Peram, At the moment, we have no standard.  We have flow accounting implementations in place already, NetFlow, CRANE, and LFAP are three of these.  They all have merits.  For us to say that NetFlow is the best without the concensus of the group is wrong.  What I am proposing is that we provide 3 alternatives for people to see and comment on.  These 3 alternatives will be narrowly focused (Just a section 5 equivalent definition) enough so that the overlapping information is removed, and they can focus on what is there.  From the concensus of the WG people, we can create SYNERGY from the 3 proposals and build our standard. In this first draft, there is no rule that says we have to have a polished protocol.  The Rough concensus of the IPFIX WG needs to be asked for.  I expect the first draft will be the most important to get our thoughts across.  After Minneapolis, we will have an emerging standard from these presented. We do not not have to have 100% approval, althoug that would be our dream.  Remember, that for a standard to be accepted, we need rough concensus and running code.  Not one or the other, but both. K.C. 

      ----- Original Message -----
      From: Peram Marimuthu
      To: K.C. Norseth
      Cc: [email-masked] ; Norseth, KC ; [email-masked]
      Sent: Saturday, February 16, 2002 9:06 AM
      Subject: Re: [ipfix] IPFIX Design draft updates
       Having 3 alternatives loses the meaning of standardization. 
      Peram 

      "K.C. Norseth" wrote: 

          ----- Original Message -----
          From: Kevin Zhang
            
            IPFIX People. 

            Changes to the drafts: 

            Architecture: 

            K.C.

---

From: [email-masked]
Date: Mon, 18 Feb 2002 10:23:29 -0500

Just FYI, I have no intentions on summitting an
LFAP version of IPFIX for consideration. More 
on this in the next mail.

Paul

---

From: [email-masked]
Date: Tue, 19 Feb 2002 15:13:15 -0500

> on this in the next mail.

	A few people contacted me on this mail so 
	let me clarify. I'm not submitting LFAP
	at this point because I think it is too
	early in the process and the selection
	criteria has not been well defined. Once
	it is, if I believe LFAP is a good fit
	(with enhancements of course) I will
	submit a proposal at that time.

	Paul