Subject: Re: PROTO-12: The observation point report interpretation

From: Juergen Quittek <[email-masked]>
Date: Thu, 02 Mar 2006 15:56:04 +0100

--On 2/28/06 11:41 PM +0100 Benoit Claise wrote:

> 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

This would work as long as there is never a confusion between
a selector ID and one of the types used for specifying the
observation point.  We would avoid this potential hazard by using
the observationPointId.  The disadvantage in that case would be the
need for another option record that specified the observation point
identified by that ID.

> 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

I do not like this approach.  If we keep the IE observationPointId,
there is no need to care about the position in the option record
where it occurs, because its semantics is always clear.

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

What about a combination of 1. and 3.?
We could allow 1. for simple observation points that can be
unambiguously identified by an identifier such as the lineCardId.
In case of a complex observation point, say three line cards,
we could use an observationPointId and have another option record
that defines the observation point that is identified by
observationPointId.

    Juergen

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

--
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: Thu, 02 Mar 2006 16:55:51 +0100

Juergen Quittek wrote:
>> 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
Yes, yet another option template record...
> where it occurs, because its semantics is always clear.
This rule has been proposed specifically so that the order is not important.
> that defines the observation point that is identified by
We could go for that solution, even if I think that it adds complexity 
to the protocol
However, I don't think that this is a good idea to specify this new 
option template record with scope=observationPointId, as it can quickly 
become complex and asy ou have to define the logic between multiple I.Es
Example:
    - logical OR of three line cards?
    - logical AND of ingress line card and egress line card ?
    - <ingressInterface, LineCard> means AND, OR, CONTAINED
So I would propose a generic sentence such as: "if the 
observationPointId is used in the Selection Sequence Report 
Interpretation, another options template record should clearly described 
the meaning of the observationPointId"

Regards, Benoit.
>> 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
>> 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
>> 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.

---

From: Andrew Johnson <[email-masked]>
Date: Thu, 02 Mar 2006 16:25:59 +0000

>> --On 2/28/06 11:41 PM +0100 Benoit Claise wrote:
[SNIP]
>>> or routerId) to define the observation point
[SNIP]
> the meaning of the observationPointId"

If we simply go for 1 for now, then this does not preclude 3 being added
later.  The simple case will have an easily identifiable I.E. in the report.
In the complex case a new element with clear semantics can be assigned by
IANA when needed and used as the observation point identifier.  Further
detail on the new element can be given by an option record separately.  This
is just like using a generic observationPointId, but the new elements can be
given clearer meaning (e.g. interfaceGroupId => interfaceId 1, 2 AND 3).

Andrew

---

From: Benoit Claise <[email-masked]>
Date: Thu, 02 Mar 2006 23:16:06 +0100

Andrew, Juergen,
>> We could go for that solution, even if I think that it adds 
>> complexity to the protocol
>> option template record with scope=observationPointId, as it can 
>> quickly become complex and asy ou have to define the logic between 
>> multiple I.Es
>> Example:
>> Interpretation, another options template record should clearly 
>> described the meaning of the observationPointId"
>
I fully agree with this.

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 03 Mar 2006 01:31:51 +0100

>> given clearer meaning (e.g. interfaceGroupId => interfaceId 1, 2 AND 3).

Also fine with me.

Thanks,

    Juergen