[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New version of the protocol draft draft-ietf-psamp-protocol-03.txt

Dear all,

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 document? 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 [PSAMP-TECH] 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 mention UDP. PROTO-06 Even if the notion of Associations ID is mentioned in [PSAMP-TECH], maybe a term such as SelectionPath or PathID would be more appropriate. 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. Two questions: 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 this. 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- psamp-framework-04.txt. 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 publication 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).

Regards, Benoit.

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/>