[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft PSAMP minutes
No one is proposing a hack configuration protocol. It has to be done right.
Simply because
it is non-trivial work doesn't mean it shouldn't be done. There are many people
willing to do the
work.
Regards,
Alex.
Andy Bierman wrote:
---X-----------------------------
>
> >Besides, why have two messaging paths, one for
> >configuration
> >and the other for data collection when you can have one do both functions?
>
> This is not a compelling reason either. Inventing a new
> protocol requires new work to support it. Replicating all
> the functions of configuration (e.g., security, access control,
> data naming) is non-trivial. A hack configuration protocol
> without any security is not a valid option.
>
> >Regards,
> >Alex.
>
> Andy
>
> >Juergen Quittek wrote:
> >
> >> Dear all,
> >>
> >> Below please find a draft of the minutes of the PSAMP session
> >> in San Francisco.
> >>
> >> Comments, corrections and extensions are very welcome!
> >> If I do not get any feedback, I will submit them as they
> >> are by the end of the week.
> >>
> >> Cheers,
> >>
> >> Juergen
> >> --
> >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15
> >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55
> >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de
> >>
> >> ==========================================================================
> >>
> >> PSAMP meeting on March 21, 2003
> >> reported by Juergen Quittek
> >>
> >> The meeting had about 45 attendees.
> >>
> >> =====================================
> >> Any Bierman on WG and document status
> >> =====================================
> >>
> >> Andy gave an overview of the session: three documents are to be
> >> discussed covering framework, packet selection and harmonization
> >> with the IPFIX WG. For the first two documents he hopes they can
> >> be delivered in May as planned. Between these two documents,
> >> minor issues need to be clarified including terminology.
> >> Working group last call is planned for end of April.
> >>
> >> The PSAMP MIB document was not on the agenda. Work on it will
> >> start in April. Volunteers for writing the PSAMP MIB are still
> >> welcome. Please contact the chairs.
> >>
> >> Conformance issues for PSAMP systems are to be discussed today.
> >> Minimum requirements include a single observation point, a single
> >> standard sampling algorithm and export using PSAMP format and
> >> protocol.
> >>
> >> ====================================
> >> Nich Duffield on the PSAMP framework
> >> ====================================
> >>
> >> Nick reported on the changes in the PSAMP framework document
> >> <draft-ietf-psamp-framework-02.txt> since the last meeting.
> >>
> >> The selection operation was just a binary decision, now it is
> >> the selected packet. This simplifies expressing ordered composite
> >> selection operations.
> >>
> >> Now, each selector keeps the number of input packets and reports
> >> it as sequence number.
> >>
> >> Basic packet selection can be count-based or timer-based. Past
> >> studies showed that count-based selection is more accurate.
> >> Still both will be supported by PSAMP. Further supported selection
> >> methods include random sampling, 1 in N sampling and hash based
> >> sampling. There are more candidates, but it is an open question,
> >> how much of them can be specified.
> >>
> >> Filtering is the selection based on packet fields and packet
> >> treatment. Filtering will not be a mandatory feature of PSAMP
> >> devices. Routers already do filtering with ACLs, but filtering
> >> for PSAMP can be easier than filtering with ACLs.
> >>
> >> Composite selection operations are nice to have, but it is not yet
> >> clear if we need complex composition capabilities. The current
> >> proposal is to just offer either (1) first sampling, then
> >> filtering or (2) first filtering, then sampling.
> >>
> >> It was under discussion whether there shall be a set of mandatory
> >> packet selection methods or whether just a single arbitrary one
> >> MUST be supported by a PSAMP device. But according to the
> >> discussion during Andy's presentation the group agreed on a
> >> single arbitrary one.
> >>
> >> Reporting MUST support the following reports:
> >> - first N bytes of packet
> >> - sequence numbers
> >> - device interface serving as observation point
> >> - attributes calculated during sampling: hash, timestamp, ...
> >>
> >> There were no changes in the export process, but there are some
> >> expected depending on our evaluation of DCP and PR-SCTP, and on
> >> the IPFIX protocol choice.
> >>
> >> Question by unknown person: How will the observation point be
> >> specified? By logical or physical interface ID?
> >>
> >> Juergen, Andy: the physical seems to be always required, the
> >> logical one can be optional. Anyway, the observation point need
> >> to be clearly identified.
> >>
> >> ===============================
> >> Tanja Szeby on Packet Selection
> >> ===============================
> >>
> >> Tanja reported on progress with the document on packet selection
> >> <draft-ietf-psamp-sample-tech-01.txt>.
> >>
> >> In conformance with Andy and Nick, Tanja stated that there are no
> >> MANDATORY sampling schemes but if one is supported, than this
> >> scheme need to be precisely defined by the standard and the
> >> implementation MUST comply to this.
> >>
> >> Nick: We need to clarify if hash-based sampling is a kind of
> >> content-based sampling?
> >>
> >> Is content-based sampling other than hash-based required at al?
> >>
> >> Andy: Does anyone have a strong feeling on whether to have no particular
> >> scheme mandatory, but just the support of at least one of them? Please
> >> send comments to the list.
> >>
> >> ==================================
> >> Benoit Claise on relation to IPFIX
> >> ==================================
> >>
> >> Benoit explained the similarities and differences in
> >> architecture and terminology of IPFIX and PSAMP. Terminology
> >> should be consistent between the two groups.
> >>
> >> Also mutual re-use of technologies is possible. The IPFIX WG
> >> has chosen NetFlow version 9 as starting point for protocol
> >> development. NetFlow v9 is template-based.
> >>
> >> Andy: at least one reporting template per observation point need
> >> to be available in order to differentiate observation point.
> >>
> >> Juergen: There should be one report configuration per
> >> observation point.
> >>
> >> Peter Phaal: There might be a problem with using templates
> >> for PSAMP.
> >>
> >> Benoit: There should be no problem with templates.
> >>
> >> Andy: There is a problem with template-based reporting, because
> >> variable length fields are not yet supported.
> >>
> >> Benoit: This was also discussed in IPFIX the day before and it
> >> is identified as a shortcoming to be fixed.
> >>
> >> Unknown person: It looks like the group focuses on routers
> >> and switches. Are workstations also in the scope?
> >>
> >> Andy: Yes.
> >>
> >> Unknown person: Why would the readable MIB be a MUST
> >>
> >> After a short discussion, read-only support of the
> >> PSAMP MIB was not considered as mandatory. For small sampling
> >> devices, supporting the MIB could be a too strong requirement.
> >>
> >> Nick pointed out some terms that need alignment between
> >> PSAMP and IPFIX: field <-> attribute,
> >> PSAMP device interface <-> observation point
> >>
> >> Nick: We should use SNMP for configuration
> >>
> >> Andy: How does the WG feel about using the IPFIX protocol for exporting?
> >>
> >> Unknown person: we have a measurement tool running that uses TCP-based
> >> proprietary communication.
> >>
> >> It was agreed to continue this discussion on the mailing list.
> >>
> >> --
> >> to unsubscribe send a message to psamp-request@ops.ietf.org with
> >> the word 'unsubscribe' in a single line as the message text body.
> >> archive: <http://ops.ietf.org/lists/psamp/>
> >
> >
> >--
> >to unsubscribe send a message to psamp-request@ops.ietf.org with
> >the word 'unsubscribe' in a single line as the message text body.
> >archive: <http://ops.ietf.org/lists/psamp/>
--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>