[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PROTO-12: The observation point report interpretation

Juergen Quittek wrote:



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

Yes, yet another option template record...



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.

This rule has been proposed specifically so that the order is not important.



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


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