PROTO-12: The observation point report interpretation

[Benoit Claise <bclaise@cisco.com>]

Dear all,

During the last IETF meeting, we discussed the PSAMP issue 12.

   PROTO-12 Discuss how to implement the observation point report 
   interpretation (if we need one) 

The "Associations Report Interpretation" in http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-03.txt, which BTW has been renamed to "Select Path Report Interpretation", currently contains the observationPointId information element, amongst others:

    Scope:     selectionPath 
    Non-Scope: observationPointId 
               selectorId (one or more) 

Note that the section also specifies: 

   The observationPointID SHOULD be first Information Element and the 
   optional processes SHOULD be last ones so that the path of the 
   selected Packet is provided in the logical order. 

[PSAMP-INFO] currently specifies: 

6.2.19 observationPointId

Description:
ID of the observation process. Unique in the observation domain.
Abstract Data Type: octet
ElementId: 320

The issue is that a mapping between the observationPointId and the existing information element(s) such as interfaceId, lineCardId, or routerId is required, adding some complexity in PSAMP, as yet another option template is required.
The proposal is that:
1. we don't define the observationPointId in [PSAMP-INFO], but we use the any information element (such as interfaceId, lineCardId, or routerId) to define the observation point
2. as the "Select Path Report Interpretation" is composed only of one observation point and selector Id(s), we simply assume that the non-selector ID(s) is the observation point. This way, we avoid the sentence "The observationPointID SHOULD be first Information Element and the optional processes SHOULD be last ones ." that impose a new rule in IPFIX: the meaning of a specific I.E. depends on the order of the I.E. in the record
3. If a more complex observation point is required such as an unique ID representing a list of interfaces, a new Information Element is defined and can be used right away.

Note: an alternate solution would be to have 2 scopes in the "Select Path Report Interpretation": the selectionPath, and the observation point. However, this was not considered as a clean solution.

Here is the text proposal

Selection Path Report Interpretation

Each Packet Report contains a selectionPath Information Element that identifies the particular combination of Observation Point and Selector(s) used for its selection.  For every selectionPath Information Element in use, the PSAMP Device MUST export a Selection Path Report Interpretation using an Options Template with the following Information Element:

 Scope:          selectionPath
 Non-Scope: one Information Element representing the Observation Point
                     selectorId (one or more)

The Information Element representing the Observation Point would typically be taken from the ingressInterface, egressInterface, lineCardId, exporterIPv4Address, exporterIPv6Address (specified in [IPFIX-INFO]), but not limited to those: any Information Element specified in [IFPIX-INFO] or [PSAMP-INFO] can potentially be used. In case of more complex Observation Points (such as a list of interfaces, a bus, etc..), a new Information Element describing the new type of Observation Point must be specified, along with an option template record describing it in more details (if necessary).

If the packets are selected by a Composite Selector, the Selection Path is composed of several Primitive Selectors.  In such a case, the Selection Path Report Interpretation MUST contain the list of all the Primitive Selector IDs in the Selection Path.  If multiple Selectors are contained in the Selection Path Report Interpretation, the Selectors ID MUST be identified in the order they are used.

Any feedback?

Regards, Benoit.