Subject: [ipfix] Selecting a protocol

From: "Harrington, David" <[email-masked]>
Date: Mon, 18 Feb 2002 13:30:41 -0500

Hi,

I'm a little confused about the goals and the steps we're taking to get
there.
Randy points out that the goal is to *select a protocol*, and the selected
protocol should have all the benefits, use congestion-aware transport, and
not be encumbered.

Of these three requirements, two are simple binary conditions. Does this
mean we can eliminate some of the proposed protocols using these binary
conditions?

Which of the proposed protocols are congestion-aware and not encumbered?

Of the proposals that are not congestion-aware, is there a way to define a
manner of usage that would provide such congestion-awareness for the
protocol, without modifying the protocol?

Of the proposals that are currently encumbered, do we have statements from
vendors to eliminate the legal and financial burdens from their proposals?
Are there any encumbrances that have not yet been identified by vendors?

Should the protocols that do not meet these conditions be eliminated from
the drafts?
If we do this, which proposals do we have left to consider?

Randy, as AD can you tell us, are there also requirements for addressing
security that would eliminate some proposals?

Thanks,
dbh

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]] 
> Sent: Saturday, February 16, 2002 7:34 PM
> To: Peram Marimuthu
> Cc: [email-masked]
> Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design 
> draft updates)
> 
> 
> [ 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: Randy Bush <[email-masked]>
Date: Mon, 18 Feb 2002 10:46:04 -0800

realistically, i think you will have to modify any of the existing
protocols to meet robust needs.  and yes, i think security should
be a consideration.  [ note that snmpv3 control and tcp export over
ipsec  may meet some of the more difficult issues you raise ]

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/