Re: [IPFIX] RFC 6728: Observation Point ID definition
Gerhard Muenz <muenz@net.in.tum.de> Sat, 11 March 2017 13:14 UTC
Return-Path: <muenz@net.in.tum.de>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3792D1294A4; Sat, 11 Mar 2017 05:14:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMLPtjIEfR0a; Sat, 11 Mar 2017 05:13:59 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68F912945B; Sat, 11 Mar 2017 05:13:58 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id E1449282F000; Sat, 11 Mar 2017 14:13:50 +0100 (CET)
To: Marta Seda <Marta.Seda@calix.com>, "ipfix@ietf.org" <ipfix@ietf.org>, "ie-doctors@ietf.org" <ie-doctors@ietf.org>
References: <BY2PR0501MB17346D370676D56617BC67A49C2A0@BY2PR0501MB1734.namprd05.prod.outlook.com>
From: Gerhard Muenz <muenz@net.in.tum.de>
Message-ID: <d3d71495-7e25-af5a-1621-0968ff4d9dfb@net.in.tum.de>
Date: Sat, 11 Mar 2017 14:13:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <BY2PR0501MB17346D370676D56617BC67A49C2A0@BY2PR0501MB1734.namprd05.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------5BA4A5D252CA0A1BAC9EA559"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/zfbwBDpfi-pnQgeqlh_e0gyosYc>
Subject: Re: [IPFIX] RFC 6728: Observation Point ID definition
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Mar 2017 13:14:01 -0000
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 > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix
- [IPFIX] RFC 6728: Observation Point ID definition Marta Seda
- Re: [IPFIX] RFC 6728: Observation Point ID defini… Gerhard Muenz