Dan,
Thanks for your comments. Please find the proposed changes below, except
for
T5 (Security) and E5 {Privacy), which will be dealt with in a separate
message; and E7, for which the response needs to be coordinated with
authors of the PSAMP sampling techniques draft.
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca(_at_)avaya(_dot_)com]
Sent: Wednesday, October 24, 2007 10:55 AM
To: ietf(_at_)ietf(_dot_)org
Cc: psamp(_at_)ietf(_dot_)org
Subject: [PSAMP] RE: Last Call: draft-ietf-psamp-framework (A
Framework
forPacket Selection and Reporting) to Informational RFC
Here are my Technical and Editorial comments:
T1: page 19, Section 6.1 -
The Metering Process must support inclusion of the following in
each Packet Report, as a configurable option:
(iii) a basic report on the packet, i.e., some number of
contiguous bytes from the start of the packet, including
the
packet header (which includes link layer, network layer and
other encapsulation headers) and some subsequent bytes of
the packet payload.
In most cases I do not know how an IP-layer networking device like a
router can access the link layer header.
Proposed change:
OLD:
(iii) a basic report on the packet, i.e., some number of
contiguous bytes from the start of the packet, including the
packet header (which includes link layer, network layer and
other encapsulation headers) and some subsequent bytes of
the packet payload.
NEW:
(iii) a basic report on the packet, i.e., some number of
contiguous bytes from the start of the packet, including the
packet header (network layer and any encapsulation headers
including MPLS) and some subsequent bytes of the packet payload.
T2: page 19, Section 6.2 - The value of the DSCP field is worth being
added to (iv)
Proposal: add it under "(v) packet treatment, including:"
T3: page 24, Section 9 - The manageability considerations should
include
not only information about how to configure the Metering Process, but
also
how to configure reporting and how to monitor the status of the
observation points and of the collectors. Also, are there any alarms
situations (congested collectors for example?)
Proposed change to Section 9:
OLD:
A key requirement for PSAMP is the easy reconfiguration of the
parameters of the Metering Process: those for selection, packet
reports and export. An important example is to support
measurement-based applications that want to adaptively drill-down
on traffic detail in real-time;
To facilitate retrieval of parameters, they are to reside in a
Management Information Base (MIB). Mandatory monitoring objects
will cover all mandatory PSAMP functionality.
For configuring parameters of the Metering Process, several
alternative are available including a writeable MIB module as
well as other configuration protocols.
NEW:
A key requirement for PSAMP is the easy reconfiguration of the
parameters of the Metering Process, including those for selection and
packet reports, and of the Exporting Process. An important example is
to support measurement-based applications that want to adaptively
drill-down on traffic detail in real-time.
To facilitate retrieval and monitoring of parameters, they are
to reside in a Management Information Base (MIB). Mandatory monitoring
objects will cover all mandatory PSAMP functionality. Alarming of
specific parameters could be triggered with thresholding mechanisms such
as the RMON event and alarm [RFC-2819] or the event MIB [RFC-2981].
For configuring parameters of the Metering Process, several
alternatives are available including a MIB module with writeable
objects, as well as other configuration protocols. For configuring
parameters of the Exporting Process, the Packet Report, and the Report
Interpretation, which is an IFPIX task, the IPFIX configuration
method(s) should be used.
T4: Section 11.3 - for psamp-based Passive Performance Measurement to
play
a role in verification of SLAs, one needs to have the basic metering
process parameters be included in the definition of the SLA and how
SLA
metrics are defined and measured
Propose adding first paragraph of Section 11.3
Old:
Trajectory sampling enables the tracking of the performance experience
by customer traffic, customers identified by a list of source or
destination prefixes, or by ingress or egress interfaces. Operational
uses include the verification of Service Level Agreements (SLAs), and
troubleshooting following a customer complaint.
New:
Trajectory sampling enables the tracking of the performance experience
by customer traffic, customers identified by a list of source or
destination prefixes, or by ingress or egress interfaces. Operational
uses include the verification of Service Level Agreements (SLAs), and
troubleshooting following a customer complaint. In this case, the
relevant PSAMP Metering Process parameters would be included in the
definition of the SLA in order to define the SLA metrics and how they
are measured.
T5: Section 12 Security Considerations - this section seems to me
incomplete. For example RFC 3917 describes in its corresponding
Security
Considerations section the need to deal with the DoS and forgery
threats.
Similar information should be included here at least by reference -
e.g.
the need of authenticating collectors, protect against
mis-configuration
of the metering and reporting processes, etc.
The security issues raised here and by Ben Campbell will be addressed in
another message
E1: The two paragraphs before the Table of Contents should be deleted
OK
E2: The text after the Table of Comments until the start of Section 1
duplicates text on page 1 and should be deleted.
OK
E3: Section 3.2 - 'Examples include: a line to which a probe is
attached,
a shared medium, such as an Ethernet-based LAN, a single port of a
router,
or a set of interfaces (physical or logical) of a router.'
- what is a 'port of a router' - is it not equivalent with a physical
interface? If so I suggest to make the terminology consistent
E4: Section 3.9 - why does the 'most generic' Metering Process include
a
primitive selector. It seems to me that what is meant here is not the
'most generic' but the most simple or basic Metering Process.
PROPOSED CHANGE: generic->simple
E5: Section 4.2 - what means 'cognizant of privacy and anonymity
issues'?
This will be addressed in separate message concerning reworking of
security issues
E6: Section 5.2 - I do not like the definition of systematic count
based
sampling. It would be better if it was stand-alone and not defined by
similarity with systematic time based sampling. In any case, if it
based
on the later, the definition of systematic time based sampling should
come
first. Then there is a typo that makes the phrase even harder to
understand s/expect / except.
OK
E7: the list of filters for the Selection Process in Section 5.2, page
15: What do (iv) and (v) mean? Are these packets that failed Ingress
filtering as per RFC2827 (iv) and packets that were detected as out of
spec for (v)? Making this clear would help.
This paragraph originates in the PSAMP-TECH draft; I will clarify with
its other authors.
E8: page 18, Section 5.4 - 'The Attained Selection Fraction can be
used to
estimate the number bytes present in a portion of the Observed Packet
Stream. Let b1, b2,..., bn be the bytes reported in each of the
packets
that reached the Collector ...' s/number bytes/number of bytes/ and
s/be
the bytes/be the number of bytes/
OK
E9: page 24, Section 9 - s/writeable MIB module/MIB module with
writeable
objects/
OK
E10: Section 10 - The first paragraph is duplicated
OK
E11: Section 10.2 - The first phrase in the section could be dropped
OK
E12: Section 10.2 - Expand ASIC
OK
Please let us know whether your comments (apart from T5, R5, E7) are
addressed.
Regards,
Nick
Thanks and Regards,
Dan
-----Original Message-----
From: The IESG [mailto:iesg-secretary(_at_)ietf(_dot_)org]
Sent: Monday, October 22, 2007 4:06 PM
To: IETF-Announce
Cc: psamp(_at_)ietf(_dot_)org
Subject: Last Call: draft-ietf-psamp-framework (A Framework for
Packet
Selection and Reporting) to Informational RFC
The IESG has received a request from the Packet Sampling WG
(psamp) to consider the following document:
- 'A Framework for Packet Selection and Reporting '
<draft-ietf-psamp-framework-12.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
solicits
final comments on this action. Please send substantive comments to
the ietf(_at_)ietf(_dot_)org mailing lists by 2007-11-05. Exceptionally,
comments
may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please
retain
the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-12.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
w_id&dTag=9292&rfc_flag=0
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
PSAMP mailing list
PSAMP(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/psamp
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf