Re: [IPFIX] RFC 6728: Observation Point ID definition

[Gerhard Muenz <[e-mail]>]

Hello Marta,

Observation Point is an IPFIX term defined in RFC5101 and then RFC7011 ( 
https://tools.ietf.org/html/rfc7011#page-8 ):

    Observation Point

       An Observation Point is a location in the network where packets
       can be observed.  Examples include a line to which a probe is
       attached; a shared medium, such as an Ethernet-based LAN; a single
       port of a router; or a set of interfaces (physical or logical) of
       a router.


The ObservationPoint class defined in RFC6728 ( 
https://tools.ietf.org/html/rfc6728#section-4.1 ) allows to identify 
such an Observation Point in a Monitoring Device.

It seems that you do not want to specify a point for observing packets, 
right? Then, the ObservationPoint class is not the right class for your 
use case.

You can define your own yang module or extend the existing one with a 
new class that allows to identify your source of statistics, whatever 
that shall be.

Regards,
Gerhard


On 04.03.2017 17:21, Marta Seda wrote:
>
> Hello,
>
> RFC 6728 defines the observation point as the “location for which 
> packets are observed”.  RFC 6727 page 4.1 shows this uml relationship:
>
> +-------------------------------+
>
>          | ObservationPoint              |
>
>        +-------------------------------+
>
>          | name                          |
>
>          | observationPointId {readOnly} |
>
>          | observationDomainId           | 0..*
>
>          | ifName[0..*]                  |-------------+
>
>          | ifIndex[0..*]                 |             | 0..*
>
>          | entPhysicalName[0..*]         |             V
>
>          | entPhysicalIndex[0..*]        |    +------------------+
>
>          | direction = "both"            |    | SelectionProcess |
>
> +-------------------------------+    +------------------+
>
> In RFC 6728, the observationpointid, ifname, ifindex,entphysicalname 
> and entphysicalindex are part of the observationpointparameters grouping.
>
> RFC 6728 has examples centered around the idea of creating a metering 
> process that samples packets and reports statistics over ipfix 
> (netflow-like statistics).
>
> There is yang models that configure statistic collection.   It seems 
> in that case (if you want to use ipfix to carry those statistics), 
> that the observation point could refer to those entities (leaf-ref) 
> that are already collecting statistics.  When I look at the RFC 6728 
> yang structure it seems there is an “attempt” to do that via the use 
> of IfName, IfIndex, EntPhysicalName and EntPhysicalIndex (which are 
> SNMP physical entities).  However you have logical entities that the 
> current structure doesn’t permit you to define as the observation 
> points.  Is that a correct interpretation of the current yang for 
> ipfix?  How can you refer to logical entities? (it seems the only 
> place you could do this was to stick the leaf-ref into the name but 
> not a good yang practice).
>
> Please advise.
>
> Thanks.
>
> Marta Seda
>
>
>
> _______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix