Subject: RE: PSAMP IANA considerations section

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 3 Mar 2006 12:27:26 +0100

Dear Benoit and all,

The problem with this is that we want to have well defined selector
algorithms, right? So we register a number for each defined algorithm with
IANA and mandate a consistant description of the algorithm (propably as
RFC). So it gets difficult to have intermediate or vendor specific selector
algorithms! I would like to propose a solution for this. However it has the
drawback that it makes the definition and usage of vendor specific selector
algorithms easier and lifts the pressure of registering new algorithms with
IANA.

I would change the selectorAlgorithm Information Element from octet to
unsigned64. The content would be defined as follows:

6.2.3  selectorAlgorithm

   Description:
      Specifies the selector algorithm (e.g., filter, sampler, hash)
      that was used on a packet.  It is exported in the options data
      flow record to specify how a collector has to interpret a data
      flow record.  The Information Element should be encoded in the
      following way in an unsigned64 value:

      0                   1                   2                   3  
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |E|               Selector Algorithm Indentifier                |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                      Enterprise Number                        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

      The most significant bit must be set if the selector algorithm is
      defined by an enterprise and is not registered with IANA. The
      following 31 bits contain a Selector Algorithm Identifier. This
      is the value registered with IANA if the enterprise bit E is not
      set. Otherwise it depends on the Enterprise Number that is
      encoded in the last 32 bits. The Enterprise Number is the same
      as defined for Information Element templates. If the Enterprise
      Bit E is not set the Information Element may be reduced to an
      unsigned32 data type. If the size is not reduced then the 
      Enterprise number has to be set to 0.

      The following Selector Algorithms Identifiers are currently
      defined:
      *  1 Systematic count-based sampling
      *  2 Systematic time-based sampling
      *  3 Random n-out-of-N sampling
      *  4 Uniform probabilistic sampling
      *  5 Non-uniform probabilistic sampling
      *  6 Non-uniform flow state sampling
      *  7 Match based filtering
      *  8 Hash based filtering
      *  9 Router state filtering

      The parameters for most of these algorithms are defined in this
      information model.  Some parameters - especially those for
      algorithms 5, 6 and 8 are not covered by this information model
      since they depend very much on the underlying hardware.
      Currently there are no hash functions defined.

      EDITOR'S NOTE: This list may extend to the final version.  The
      "unsigned64" data type is probably not the best choice but keeps the
      list extensible.
   Abstract Data Type: unsigned64 
   Data Type Semantics: identifier
   ElementId: 302
   Status: current

The text may still be subject to changes if I expressed myself not clear
enough.

I hope that makes this element more flexible but still simple enough.

Best Regards,

Thomas

-- 
Thomas Dietz
Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Benoit Claise
> Sent: Monday, February 27, 2006 4:41 PM
> To: Juergen Quittek
> Cc: psamp
> Subject: Re: PSAMP IANA considerations section
> 
> Juergen,
> 
> This open issue should find a solution for the next version of the 
> draft, to be published by Monday.
> See inline.
> > --On 21.12.2005 11:14 Uhr +0100 Benoit Claise wrote:
> >
> >> Dear all,
> >>
> >> Here is a proposal for the IANA considerations section.
> >>
> >>
> >> 1. 9. IANA Considerations
> >>
> >> The PSAMP Protocol, as set out in this document, has two sets of 
> >> assigned numbers.  Considerations for assigning them are 
> discussed in 
> >> this section, using the example policies as set out in the 
> >> "Guidelines for IANA Considerations" document IANA-RFC
> >> [RFC2434].
> >>
> >>      9.1 IPFIX Related Considerations
> >>
> >> As the PSAMP protocol uses the IPFIX protocol, refer to the IANA 
> >> considerations section in [IPFIX-PROTO] for the assignments of 
> >> numbers used in the protocol and for the numbers used in the 
> >> information model.
> >>
> >>       9.2 PSAMP Related Considerations
> >>
> >> Each new selection method MUST be assigned a unique value for the 
> >> selectorAlgorithm Information Element.  Its configuration 
> >> parameter(s), along with the way to report it/them with an Options 
> >> Template, MUST be clearly specified.
> >>
> >> Each new selection method MUST be assigned a unique value for the 
> >> selectorAlgorithm Information Element.  New assignments 
> for the PSAMP 
> >> selection method will be administered by IANA, on a First 
> Come First 
> >> Served basis [RFC 2434], subject to Expert
> >> Review [RFC 2434], i.e. review by one of a group of experts 
> >> designated by an IETF Operations and Management Area 
> Director.  The 
> >> group of experts must double check the Information Elements 
> >> definitions with already defined Information Elements for
> >> completeness, accuracy and redundancy.  Those experts will 
> initially 
> >> be drawn from the Working Group Chairs and document editors of the 
> >> IPFIX and PSAMP Working Groups.
> >>
> >> Now, two questions:
> >> 1. I'm not too sure whether we should mandate a new IETF 
> RFC for the 
> >> new selection method description?
> >
> > This would be a tough requirement.  However, it would make 
> sure that the
> > new methods is well documented.
> So the text proposal is fine with you, right?
> >
> >> 2. I'm not too sure whether we should mandate new IANA-registered 
> >> information elements for the new selection method?
> >
> > Since we do not have vendor IDs in here, this is the only way of 
> > achieving
> > interoperability.
> I had in mind that the selectorAlgorithm could be specified with the 
> Entreprise Number, for proprietary purposes
> 
>        0                   1                   2                   3  
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
> 7 8 9 0 1  
>        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>        |E|  Information Element ident. |        Field Length  
>          |  
>        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>        |                      Enterprise Number               
>          |  
>        
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>       
>           Figure G: Field Specifier format 
> 
> 
> >
> >>     In other words, can we have proprietary selection 
> method in the 
> >> selectorAlgorithm Information Element?
> >
> > Can't we assign an interval, say [1024 - ...] and declare selection 
> > methods
> > with identifiers in that interval as 'experimental' or even 
> > 'implementation specific'?
> Do we need this if we use a I.E. proprietary definition with the 
> Entreprise Number?
> 
> Don't forget that the selectorAlgorithm is specified as an octet.
> 
> Regards, Benoit.
> >
> >> Regards, Benoit.
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/psamp/>
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 03 Mar 2006 23:47:17 +0100

Dear Thomas,

If I wanted to specify a new algorithm (filter, sampler, hash) private 
for my company, I would do the following:
- specify a proprietary I.E., whose name is selectorAlgorithm, exactly 
the same one as in [PSAMP-INFO]
- I would make sure I don't re-use the existing selectorAlgorithm values 
as specified in [PSAMP-INFO] and IANA
  So I would start from a higher range.

What I'm describing is already possible with IPFIX, as a generic 
mechanism. Section 3.2 of [IPFIX-PROTO] doesn't preclude the use an 
existing IPFIX I.E. name as an enterprise specific I.E.
As this is a generic mechanism, why limit this to the selectorAlgorithm 
I.E. description?
Example 1: I want to redefine the octetDeltaCount with an Entreprise ID 
to contain the MPLS header
Example 2: I want to add some extra reasons to the flowEndReason
So why not add the same remark in some other I.E. description?

So I fail to understand what we gain by adding this in the Information 
Element description?
It doesn't even simplify the Collector job:
- If it receives selectorAlgorithm without Enterprise ID, it knows where 
to look up the meaning
- If it receives selectorAlgorithm with Enterprise ID, it must look in 
the specific enterprise registry.

In conclusion, I don't see the need for explaining in a I.E. description 
what is possible by the IPFIX protocol

Regards, Benoit.