[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft PSAMP minutes
Given the intense debate as to whether or not the IPFIX protocol selection
process was
fair, I'd prefer this WG to develop its own Export protocol. That'll give us
an opportunity
to fix all the shortcomings that may be inherent in the IPFIX protocol.
I've always argued for using TLV messages to configure the PSAMP device. It
allows for
better control of availability and fail-over management. I am not sure if
configuration via
SNMP will be that responsive. Besides, why have two messaging paths, one for
configuration
and the other for data collection when you can have one do both functions?
Regards,
Alex.
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/>