Re: [IPFIX] [Sender: [email protected]] RFC5101: time first flow dropped and time last flow dropped
Benoit Claise <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Hi Gerhard, > > Dear all, > > On 20.09.2011 22:32, Paul Aitken wrote: >> Benoit, >> >>> 2. if the IPFIX exporter is configured from [IPFIX-CONF], what should >>> be the value in meteringProcessId? >>> [IPFIX-CONF] doesn't mention the meteringProcessId, but a cache >>> name. >> >> IPFIX-CONF (or any configurer) wouldn't set the process ID; it's >> read-only. >> >> The configurer would create the process (technically, add the config >> which causes the process to be created by the OS), then could be told >> (or could discover) what the process ID is. >> The cache name could be used to relate the given config to the >> process ID. > > Correct. In general, IDs cannot be considered to be configurable. > >>> From figure 1 and 2, it seems that there is a one to one matching >>> between the cache and the metering process. >>> If this is the case, a solution could be to add a meteringProcess >>> inside the cache in the figure 12 in [IPFIX-CONF] below >> >> Do you mean, a "meteringProcessId" (IANA #144) as a read-only property? >> >> And also an "exportingProcessId" (IANA #145) as a read-only property in >> the ExportingProcess? > > I'm not sure about the one-to-one relationship between Metering > Process and Cache. On purpose, IPFIX-CONF does not make a statement > because it is not an architectural document. A Metering Process may > have multiple Caches. But I do not think that a Cache would belong to > multiple Metering Process. So, there is only one meteringProcessId > which is associated with a Cache. > > We do not have selectorId, exportingProcessId, and meteringProcessId > in the configuration data model. If we think about adding > meteringProcessId, it may be worth thinking about the other IDs as well. > > I do not see a problem if these are defined as state parameters (e.g. > read-only). Great. I propose to add them in the AUTH48 process. Regards, Benoit. > > selectorId is a bit different because the scope is OD, not IPFIX > device. Therefore, the same ID value may appear for different > Selectors of the same device. > > Gerhard _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix