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@xxxxxxxxx]
> Sent: Wednesday, October 24, 2007 10:55 AM
> To: ietf@xxxxxxxx
> Cc: psamp@xxxxxxxx
> 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@xxxxxxxx]
> > Sent: Monday, October 22, 2007 4:06 PM
> > To: IETF-Announce
> > Cc: psamp@xxxxxxxx
> > 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@xxxxxxxx mailing lists by 2007-11-05. Exceptionally,
comments
> > may be sent to iesg@xxxxxxxx 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@xxxxxxxx
> > https://www1.ietf.org/mailman/listinfo/ietf-announce
> >
>
> _______________________________________________
> PSAMP mailing list
> PSAMP@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/psamp
_______________________________________________
Ietf@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf