Subject: [IPFIX] IPFIX observationPointId uniqueness

From: Paul Aitken <[email-masked]>
Date: Fri, 01 Feb 2013 09:45:07 +0000

Dear IPFIX experts,

IPFIX observationPointId (#138) is defined as:

          An identifier of an Observation Point that is unique per
          Observation Domain.  It is RECOMMENDED that this identifier is
          also unique per IPFIX Device.  Typically, this Information
          Element is used for limiting the scope of other Information
          Elements.

We now also have observationPointType (#277), defined as:

           Type of observation point. Values assigned to date are:

           1. Physical port
           2. Port channel
           3. Vlan.

Could we relax the uniqueness requirements of observationPointId when an 
observationPointType is also exported, such that the { 
observationPointType, observationPointId } pair must be unique, though 
not the observationPointId itself.

The reason being that observation points of different types already have 
IDs, though these are not unique. eg, we have interface 1, 2, 3, ...; 
vlan 1, 2, 3, ...; port 1, 2, 3, ...

So an extra mediation layer is required to convert values from each of 
these number spaces into unique IDs in the observationPointId number 
space - which becomes harder as we add more places that observations can 
be made, ie more observationPointTypes.

Whereas prefixing with the observationPointType achieves the required 
uniqueness in a faster, simpler, and more reliable way.

To achieve this, I'd propose the following definition change:

          An identifier of an Observation Point that is unique per
          Observation Domain and per observationPointType, if specified.
          It is RECOMMENDED that this identifier is
          also unique per IPFIX Device.  Typically, this Information
          Element is used for limiting the scope of other Information
          Elements.

For backwards compatibility, we could define observationPointType = 0 to 
be "unspecified".

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 1 Feb 2013 11:16:12 +0100

hi Paul,

Sounds reasonable to me.

Cheers,

Brian

On 1 Feb 2013, at 10:45 , Paul Aitken wrote:

> Could we relax the uniqueness requirements of observationPointId when an observationPointType is also exported, such that the { observationPointType, observationPointId } pair must be unique, though not the observationPointId itself.
> 
> The reason being that observation points of different types already have IDs, though these are not unique. eg, we have interface 1, 2, 3, ...; vlan 1, 2, 3, ...; port 1, 2, 3, ...
> 
> So an extra mediation layer is required to convert values from each of these number spaces into unique IDs in the observationPointId number space - which becomes harder as we add more places that observations can be made, ie more observationPointTypes.
> 
> Whereas prefixing with the observationPointType achieves the required uniqueness in a faster, simpler, and more reliable way.
> 
> For backwards compatibility, we could define observationPointType = 0 to be "unspecified".
> 
> Thanks,
> P.
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Feren <[email-masked]>
Date: Mon, 04 Feb 2013 17:19:39 -0500

Hi Paul,

This seems like a good idea.

-Andrew

On 02/01/2013 04:45 AM, Paul Aitken wrote:
> Could we relax the uniqueness requirements of observationPointId when 
> an observationPointType is also exported, such that the { 
> The reason being that observation points of different types already 
> have IDs, though these are not unique. eg, we have interface 1, 2, 3, 
> ...; vlan 1, 2, 3, ...; port 1, 2, 3, ...
>
> space - which becomes harder as we add more places that observations 
> can be made, ie more observationPointTypes.
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 15 Feb 2013 01:23:44 +0100

Paul,

At first glance, it looks reasonable.
But what would be the consequence on the Selection Sequence Report 
Interpretation(see http://tools.ietf.org/html/rfc5476#section-6.5.1). If 
we use the observationPointId and it's not unique, then we need to 
include the observationPointType?
Note that the sentence "It is RECOMMENDED that this identifier is also 
unique per IPFIX Device." was inserted specifically for this.

Regards, Benot

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 15 Feb 2013 10:25:39 +0100

Benoit, Paul,

Like Benoit, I do not have a good feeling about this proposal. On the 
other hand, I have not found any RFC that really requires the use of 
OPIDs. Even RFC5476 leaves it open whether the OP is identified by OPID 
or any other IE. Therefore, I have been silent until now.

IPFIX-CONFIG assumes that the OPID is assigned by the IPFIX device, i.e. 
it is not a configuration parameter. I think that we agree here.

Up to now, the IPFIX RFCs do not impose any restriction on the OPID 
except for the uniqueness per OD. This means that various 
implementations are possible right now:
1) OPID is equal to an internal identifier (e.g. internal interface 
number) or a non-IPFIX MIB index (e.g. ifIndex, entPhysicalIndex).
2) OPID is equal to the IPFIX-MIB index ipfixObservationPointIndex
3) OPID is unrelated to any other index, the IPFIX device provides the 
internal mapping

If IPFIX-MIB is supported by the device, the natural choice for me would 
be 2). This would allow easy mapping of MIB entries and IPFIX export.

As Paul points out, 1) only works as long as the internal identifiers 
are unique per OD.

My questions to Paul are:
- Do you really need OPID for your purpose? Have you thought about using 
IEs like ingressPhysicalInterface or ingressInterface? Or, if these IEs 
are not appropriate, about defining new IEs?
- If you need to use OPIDs and if you want to avoid any mapping, have 
you thought about assigning the different sources (interface cards, 
VLANs) to different ODs?

Regards,
Gerhard