Subject: PROTO-12: The observation point report interpretation

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Feb 2006 23:41:12 +0100

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.