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

Re: PROTO-12: The observation point report interpretation



--On 3/2/06 11:16 PM +0100 Benoit Claise wrote:

Andrew, Juergen,
Benoit Claise wrote:
Juergen Quittek wrote:
--On 2/28/06 11:41 PM +0100 Benoit Claise wrote:
[SNIP]
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
[SNIP]
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"

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).
I fully agree with this.

Also fine with me.

Thanks,

   Juergen

Regards, Benoit.


Andrew




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