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

[Benoit Claise <bclaise@cisco.com>]

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