[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New version of the protocol draft draft-ietf-psamp-protocol-03.txt
- To: psamp <email@example.com>
- Subject: New version of the protocol draft draft-ietf-psamp-protocol-03.txt
- From: Benoit Claise <firstname.lastname@example.org>
- Date: Fri, 23 Dec 2005 14:36:09 +0100
- User-agent: Thunderbird 1.5 (Windows/20051201)
As promised during the last IETF meeting in Vancouver, a new version of the PSAMP protocol draft has just been posted.
Many issues have been closed:
PROTO-01 [PSAMP-FMWK] mentions the optional Export Packets
compression (see section 8.5) Should we mention this in this
PROTO-02 From a protocol point of view, there a no differences
between the Field Match Filtering and the Router State Filtering as
defined in [PSAMP-TECH]. The only difference concerns the I.E. on
which we do the filtering... part of the packet in one case, not part
of the packet in the other case. Proposal: merge the 2 methods in
PROTO-03 The second open issue is concerned with reporting the
sequential order of sampling and filtering. => order of the scope.
We spot a new problem: we could export twice the hash value. How to
distinguish them? How to know that the hash value 1 corresponds to a
specific definition specified in an Option Template.
PROTO-05 Transport protocol: SCTP and/or UDP and/or TCP. Nothing is
mentioned at this stage. [PSAMP-FMWK] and PSAMP charter specifically
PROTO-06 Even if the notion of Associations ID is mentioned in
[PSAMP-TECH], maybe a term such as SelectionPath or PathID would be
PROTO-07 Even if [PSAMP-TECH] section 7.1 and 7.2 describes that "The
ASSOCIATIONS field describes the Observation Point and optionally the
IPFIX processes to which the packet Selector is associated. Values:
<STREAM ID, IPFIX Metering process ID, IPFIX Exporting process ID,
IDs of other associated processes>", we can't see an example where
the IPFIX process(es) ID would be required. Don't we have enough with
the list of Selector IDs?
PROTO-09 "The algorithm specific Information Elements, defining
configuration parameters for match-based and router state filtering,
are taken from the full range of available IPFIX Information Elements
[IPFIX-INFO]". What about the ones from [PSAMP-INFO]? In other words,
are they I.E.s in [PSAMP-INFO] that we could use for the match-based
and router state filtering?
PROTO-13 The solution in this document is based on the fact that
https://psg.com/lists/psamp/psamp.2005/msg00050.html is taken into
account. That means: no range for the filtering
Note that some open issues have been listed in this version of the draft
PROTO-16 IANA considerations section to be completed.
1. I'm not too sure whether we should mandate a new IETF RFC for the
new selection method description?
2. I'm not too sure whether we should mandate new IANA-registered
information elements for the new selection method?
In other words, can we have proprietary selection method in the
selectorAlgorithm Information Element?
PROTO-17 "Encrypted Packets: Selectors that interpret packet fields
must be configurable to ignore (i.e. not select) encrypted packets,
when they are detected". "Since packet encryption alters the meaning
of encrypted fields, field match filtering must be configurable to
ignore encrypted packets, when detected." I guess we will need extra
text for this.
PROTO-18 "The exporting process must have an export rate limit,
configurable per Exporting Process". I guess we need extra text for
PROTO-19 "the timestamp of observation of the packet at the
Observation Point. The timestamp should be reported to microsecond
resolution." Nothing is mentioned in this draft regarding this issue.
PROTO-20 Hash based filtering to be completed.
Regarding the action items, some have been closed:
PROTO-102 insert double spaces after the end of each sentence.
PROTO-103 Should briefly discuss the fact that PSAMP is OK with IPFIX
requirements in terms of time (uSec precision)
PROTO-105 Section 6 about "PSAMP requirements": check if any changes
with the version 5 of [PSAMP-FMWK]. This draft is based on ietf-
PROTO-107 All the examples in section 7 should contain the
Information Element ID instead of the Information Element name.
Example: Option 3 = samp.PacketSpace
Corrected Example: Option 3 = 305
However, there are still a couple of action items:
PROTO-101 See EDITOR'S NOTE
PROTO-104 Fix the terminology sections, as a last step before
PROTO-106 Extend security considerations by a discussion on exported
Payload. Consider whether [PSAMP-INFO] or [PSAMP-PROTO] or both
is/are the place(s).
PROTO-107 Provide the equivalent for variable length I.E.
Here is an example of a basic Packet Report, with a SelectionPath
value of 9 (will be explained later on) and ipPacketSection
Information Element of 12 bytes, encoded with a fixed length.
To be put in section 7.3.1
PROTO-108 Have a statement that this protocol specification
meets all requirements for the PSAMP protocol stated in the framework
except ... An then have a list of bullets, where at minimum there is
stated "not yet covered" or a longer explanation why it is not
covered. This would be replacement for the long list of requirements
in section 6.1
The goal is to post a final draft version, with all open issues solved, by the IETF deadline (should be around the beginning of March).
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.