Subject: [IPFIX] WGLC comments on draft-ietf-ipfix-configuration-model-04

From: Brian Trammell <[email-masked]>
Date: Mon, 1 Mar 2010 13:46:39 +0100

Greetings, all,

I have reviewed draft-ietf-ipfix-configuration-model-04 in response to the WGLC, and have the following comments, ranked in order of impact; most of these deal with the applicability of the configuration data model to implementations other than the "exemplar" implementation(s) the authors had in mind while while writing.  I will say that overall, the draft does an more than reasonable job of being generally applicable. I apologize for starting a new thread, but I have not yet had time to properly review other comments, but plan on being in Anaheim prepared to discuss those too. I have also explicitly not reviewed the YANG definition; I leave that to people with actual YANG expertise.

First and foremost is the issue of caches, as it is in cache implementation that IPFIX packet-to-flow MPs will differentiate the most from each other, and indeed most vendors should be expected to subclass this cache class for their own configuration parameters; therefore getting this right is probably the most crucial. cacheMode immediate seems like a bit of a hack, as it invalidates basically every other cache field. However, I suppose I can see it as a way to keep the class design clean (otherwise, there would be nothing to connect OP to layout/EP in a PSAMP implementation...). 

1. I'm concerned about the definition of cacheMode timeout (4.3, p. 24), as it seems to make it impossible to configure a cache to allow cache exit on TCP state tracking. Perhaps this is merely an editorial oversight?

2. Destination (4.4.1, pp .27-29) appears not to match the properties of the particular transports:

  a. can't specify a local IP address for TCP or UDP. This seems necessary on devices with multiple management interfaces, which I don't think is all that weird a deployment plan.

  b. can't specify 1..n remote IP addresses for SCTP. This breaks one of the advantages of SCTP.

  c. can't configure SCTP reliability per-template, as opposed to per destination. see 2.b.

3. Options (4.4.3, p. 30) configuration is rather odd and highly restrictive, even to the point of being unusable. The biggest problem is that RFC5473 common properties are something completely different from the options specified in 5101 and 5476. "Enable common properties", without some definition of which fields to use as common properties and under what circumstances, is not a useful directive. Secondarily, options specified in 5610 and 5655 are not covered; do we really want to amend this document every time we specify another WG-blessed options template? I'd suggest using an OptionsTemplate subclass of Template, instead, and providing the definition of common (non-5473) options templates in an appendix to the configuration data model.

4. There does not seem to be any room for logical configurable processes between selection and cache, or cache and EP. The example that comes to mind is perhaps implementation-specific [I'm mentioning this because yaf does it]: fragmentation behavior (reassemble, ignore, drop). How could I allow then for the configuration of the fragment table (given that a selection process can only reference a cache)? 

5. CacheLayout (4.3.1, p. 25) does not appear to be able to support adaptive reduced-length export (exporting, say, counters with unsigned32 unless one of them actually requires unsigned64) [yes, yaf does this too]. Though this could probably be solved with a deviation, and an additional vendor-specific CacheField attribute...

6. CacheLayout (4.3.1, p. 25) could do with an explicit example to illustrate the "unless the corresponding IE is not applicable or cannot be derived" case: I presume this is intended for dual-stack IPv4/IPv6 measurement, RFC5103 biflows, and the like? It does appear than this clause is sufficient for such cases, but I had to read this a couple of times before I understood that's what was meant.

7. Real File Readers and File Writers will probably need more than a single filename endpoint on the file system (however, most file readers and file writers in document-based workflows won't be configured using this information model...) How to handle this is probably implementation-specific; in any case, I don't have a good suggestion here, yet; perhaps we can discuss in Anaheim.

8. Is there any benefit to cascading caches as with selection processes, or rather, are the benefits of cascading caches considered in scope for this application? The simplest example would be simultaneous export of flow data as well as flow aggregate data (e.g. traffic counters per AS pair), perhaps as part of a cascading-aggregation mediator. I ask only because it seems a rather small and easily supportable change to greatly increase flexibility.

9. Destination exportMemberType appears to reference a renamed MIB object as of MIB-10; this is called ipfixExportMemberType now. I would suggest copying the complete description from MIB, because the semantics are kind of confusing otherwise (I had to read MIB, which I probably should have done by now but oh well, in order to figure out what the difference between parallel and primary was). A tertiary problem: these exportMemberTypes seem a bit restrictive (e.g. what if I want to do parallel export and also have secondaries?), but I suppose that's a MIB comment. 

10. draft-ietf-ipfix-file is now RFC5655 (the editor will catch this); since this is now an RFC, references to things "proposed" in this draft should probably be changed to things "specified" in RFC 5655.

That's about it...

Best regards,

Brian

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 01 Mar 2010 19:36:51 +0100

Hi Brian,

Thanks a lot for your review.

Data models in network management will never satisfy all people. So, 
please keep in mind that the goal of this document is to standardize a 
configuration data model that can be easily implemented by many vendors. 
There will always be additional vendor-specific parameters, and there 
will always be vendor-specific restrictions of the model. Thanks to 
YANG, there are possibilities to make restrictions and extension.

So, ask yourself if the parameters which are contained in the 
configuration data model can be easily mapped to one of the YAF command 
line options. Not the other way round.

More comments inline.

Gerhard

Brian Trammell wrote:
> Greetings, all,
> 
> I have reviewed draft-ietf-ipfix-configuration-model-04 in response
> to the WGLC, and have the following comments, ranked in order of
> impact; most of these deal with the applicability of the
> configuration data model to implementations other than the "exemplar"
> implementation(s) the authors had in mind while while writing.  I
> will say that overall, the draft does an more than reasonable job of
> being generally applicable. I apologize for starting a new thread,
> but I have not yet had time to properly review other comments, but
> plan on being in Anaheim prepared to discuss those too. I have also
> explicitly not reviewed the YANG definition; I leave that to people
> with actual YANG expertise.
> 
> First and foremost is the issue of caches, as it is in cache
> implementation that IPFIX packet-to-flow MPs will differentiate the
> most from each other, and indeed most vendors should be expected to
> subclass this cache class for their own configuration parameters;
> therefore getting this right is probably the most crucial. cacheMode
> immediate seems like a bit of a hack, as it invalidates basically
> every other cache field. However, I suppose I can see it as a way to
> keep the class design clean (otherwise, there would be nothing to
> connect OP to layout/EP in a PSAMP implementation...).

Right.

> 1. I'm concerned about the definition of cacheMode timeout (4.3, p.
> 24), as it seems to make it impossible to configure a cache to allow
> cache exit on TCP state tracking. Perhaps this is merely an editorial
> oversight?

We can allow a timeout Cache to expire a flow after a certain flow 
termination event. Is this what you propose?

Could you please provide some text how to change the following parameter 
description:

    cacheMode:  Configures the Cache Mode.  The following parameter
       values are specified by the configuration data model:
       *  immediate: Data Records expire after the first packet
       *  timeout: Data Records expire after active or inactive timeout
       *  permanent: Data Records never expire, but are periodically
          exported with interval set by exportInterval
       In the case of "immediate", PSAMP Packet Reports are generated.
       Otherwise, IPFIX Flow Records are generated.

> a. can't specify a local IP address for TCP or UDP. This seems
> necessary on devices with multiple management interfaces, which I
> don't think is all that weird a deployment plan.

This will be fixed as proposed in this mail unless anybody objects:
http://www.ietf.org/mail-archive/web/ipfix/current/msg05316.html

> of the advantages of SCTP.

I see send_connectx() in the SCTP API:
http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-21#section-8.9

However, what happens if you configure multiple remote IP addresses and 
they do not belong to the same SCTP endpoint?
What shall the Exporting Process do in this situation?

I'm not sure if it makes sense to configure multiple remote addresses 
for a single destination. It seems to be safer to configure multiple 
export destinations and to use export member type primary and secondary.

What do you think?

> c. can't configure SCTP reliability per-template, as opposed to per

As discussed long ago, Templates are not configured. The are created by 
the Exporting Process depending on the Data Records to be exported.

Therefore, there is no good place for a per-Template reliability 
parameter in the configuration data model. The only possibility would be 
to configure the reliability in the Cache, and this would be a very 
strange place to do it.

I had discussed this issue with Benoit. The conclusion was that we have 
a per-Destination parameter. If people want to configure more, they can 
come up with an extension.

If you have another convincing solution, please let me know.

> 3. Options (4.4.3, p. 30) configuration is rather odd and highly
> restrictive, even to the point of being unusable. The biggest problem
> is that RFC5473 common properties are something completely different
> from the options specified in 5101 and 5476. "Enable common
> properties", without some definition of which fields to use as common
> properties and under what circumstances, is not a useful directive.

The idea is that the Exporting Process defines common properties 
depending on the Data Records to be exported. This can be done 
dynamically (depending on the value distribution) or using knowledge 
about the configuration (e.g., if a filter ensures that the accounted 
packets are from/to a specific endpoint, this can be encoded as common 
property).

If you think that reducingRedundancy is not useful, I will remove from 
the list.

> Secondarily, options specified in 5610 and 5655 are not covered; do
> we really want to amend this document every time we specify another
> WG-blessed options template? 

Apart from reducingRedundancy, all mentioned Options type appear in the 
protocol RFCs (RFC5101, RFC5476).

Adding more parameter values for optionsType can be easily achieved with 
YANG extensions because they are specified as identities (it would note 
be possible with an enum type).

 > I'd suggest using an OptionsTemplate
> subclass of Template, instead, and providing the definition of common
> (non-5473) options templates in an appendix to the configuration data
> model.

I do not understand your proposal. There is no Template class for 
configuration.

> 4. There does not seem to be any room for logical configurable
> processes between selection and cache, or cache and EP. The example
> that comes to mind is perhaps implementation-specific [I'm mentioning
> this because yaf does it]: fragmentation behavior (reassemble,
> ignore, drop). How could I allow then for the configuration of the
> fragment table (given that a selection process can only reference a
> cache)?

You can always extend the model. For example, if fragmentation 
reassembly can be regarded as part of the Cache, you can easily define 
your own new cacheType (again, identities and identityref in YANG).

We also have implemented a lot of cool additional functionalities which 
we are going to configure by extending the model. It is not the purpose 
of this document to cover all of these.

> 5. CacheLayout (4.3.1, p. 25) does not appear to be able to support
> adaptive reduced-length export (exporting, say, counters with
> unsigned32 unless one of them actually requires unsigned64) [yes, yaf
> does this too]. Though this could probably be solved with a
> deviation, and an additional vendor-specific CacheField attribute...

Is reduced size encoding performed by the Cache or by the Exporting Process?

If you implement a Cache in hardware, it is probably easier to always 
use the maximum length and to reduce it later in the Exporting Process.
We assume that the Cache reserves a certain field length for all Data 
Records in the Cache.  (Variable-length fields are treated differently)

The ieLength specifies the field length in the Cache. The length in the 
exported Data Record can be different. Note again: we are not 
configuring a Template, here. The exported Data Record may even contain 
a completely different set of fields, for example in the case of 
reducing redundancy.

What about removing the following sentence to avoid any confusion:

	For Information Elements of
       integer and float type, the field length MAY be set to a smaller
       value than the standard length of the abstract data type if the
       rules of reduced size encoding are fulfilled (see [RFC5101],
       Section 6.2).

> 6. CacheLayout (4.3.1, p. 25) could do with an explicit example to
> illustrate the "unless the corresponding IE is not applicable or
> cannot be derived" case: I presume this is intended for dual-stack
> IPv4/IPv6 measurement, RFC5103 biflows, and the like? It does appear
> than this clause is sufficient for such cases, but I had to read this
> a couple of times before I understood that's what was meant.

Right. I tried to improve this. Please look into my reply to Lothar's 
review:
http://www.ietf.org/mail-archive/web/ipfix/current/msg05325.html

> 7. Real File Readers and File Writers will probably need more than a
> single filename endpoint on the file system (however, most file
> readers and file writers in document-based workflows won't be
> configured using this information model...) How to handle this is
> probably implementation-specific; in any case, I don't have a good
> suggestion here, yet; perhaps we can discuss in Anaheim.

I assume that the URI filename parameter is useful for many 
FileWriter/Reader implementations.  All additional parameters are 
probably very specific to the implementation.

> 8. Is there any benefit to cascading caches as with selection
> processes, or rather, are the benefits of cascading caches considered
> in scope for this application? The simplest example would be
> simultaneous export of flow data as well as flow aggregate data (e.g.
> traffic counters per AS pair), perhaps as part of a
> cascading-aggregation mediator. I ask only because it seems a rather
> small and easily supportable change to greatly increase flexibility.

Uff. I already have problems to convince people that there may be more 
than one parallel Caches in a Metering Process. Now, you even propose 
multiple Caches in a series :)

IMO, aggregation is done in an Intermediate Process, not in a Metering 
Process and therefore not in the Cache of a Metering Process.

The configuration of Mediators and Intermediate Process is out of scope 
of this document. Otherwise, we will never finish...

> 9. Destination exportMemberType appears to reference a renamed MIB
> object as of MIB-10; this is called ipfixExportMemberType now. I
> would suggest copying the complete description from MIB, because the
> semantics are kind of confusing otherwise (I had to read MIB, which I
> probably should have done by now but oh well, in order to figure out
> what the difference between parallel and primary was). A tertiary
> problem: these exportMemberTypes seem a bit restrictive (e.g. what if
> I want to do parallel export and also have secondaries?), but I
> suppose that's a MIB comment.

Andrew suggested to improve this as well.  See:
http://www.ietf.org/mail-archive/web/ipfix/current/msg05323.html
I'm open to concrete suggestions.

> 10. draft-ietf-ipfix-file is now RFC5655 (the editor will catch
> this); since this is now an RFC, references to things "proposed" in
> this draft should probably be changed to things "specified" in RFC
> 5655.

Done.

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Brian Trammell <[email-masked]>
Date: Wed, 3 Mar 2010 10:44:10 +0100

Hi, Gerhard, all,

On Mar 1, 2010, at 7:36 PM, Gerhard Muenz wrote:

> Data models in network management will never satisfy all people. So, please keep in mind that the goal of this document is to standardize a configuration data model that can be easily implemented by many vendors. There will always be additional vendor-specific parameters, and there will always be vendor-specific restrictions of the model. Thanks to YANG, there are possibilities to make restrictions and extension.
> 
> So, ask yourself if the parameters which are contained in the configuration data model can be easily mapped to one of the YAF command line options. Not the other way round.

Yep, I understand the point of the data model here... and YAF's configuration by its nature will most probably remain command-line (indeed I was thinking of implementing this in a Ruby script that kicked off YAF); the references to YAF herein were merely an attempt to use one specific implementation (with which I am familiar) as a tool for evaluating the flexibility and general applicability of the configuration data model. "This is out of scope" is a perfectly reasonable response. bue I wanted to make sure in reviewing that the flexibility we can get out of yang is presented in the right way... Indeed, in the selector->cache->ep chain, you can probably just model intermediate processes (like YAF's partial reassembly) as being part of the Cache, and that's just fine.

> We can allow a timeout Cache to expire a flow after a certain flow termination event. Is this what you propose?

Basically, yes. Most flow generators will expire a flow after a TCP FIN or RST (or some number of these), so there is a difference between expiring flows only on timeout and expiring on timeout as well as "natural" end of flow (see the definition of flowEndReason, IE 136). So I would propose the following:

  cacheMode:  Configures the Cache Mode.  The following parameter
     values are specified by the configuration data model:
     *  immediate: Data Records expire after the first packet
     *  timeout: Data Records expire after active or inactive timeout
|    *  natural: Data Records expire after active or inactive timeout, or
|       on natural termination (e.g. TCP FIN, or TCP RST) as determined
|       by the Metering Process.
     *  permanent: Data Records never expire, but are periodically
        exported with interval set by exportInterval
     In the case of "immediate", PSAMP Packet Reports are generated.
     Otherwise, IPFIX Flow Records are generated.

Alternately, if "timeout" meant "timeout + natural" in this terminology, we could change it as follows:

  cacheMode:  Configures the Cache Mode.  The following parameter
     values are specified by the configuration data model:
     *  immediate: Data Records expire after the first packet
|    *  timeout: Data Records expire after active or inactive timeout, or
|       on natural termination (e.g. TCP FIN, or TCP RST) as determined
|       by the Metering Process.
     *  permanent: Data Records never expire, but are periodically
        exported with interval set by exportInterval
     In the case of "immediate", PSAMP Packet Reports are generated.
     Otherwise, IPFIX Flow Records are generated.

I'm inclined toward the first alternative, with 'natural' as default and 'timeout' provided for MPs that don't want to be bothered with TCP state.

> http://www.ietf.org/mail-archive/web/ipfix/current/msg05316.html

Perfect.

> However, what happens if you configure multiple remote IP addresses and they do not belong to the same SCTP endpoint?

What sctp_connectx() does: 

"The way the SCTP stack uses the list of addresses to set up the association is implementation dependent.  This function only specifies that the stack will try to make use of all the addresses in the list when needed." The assumptions are 1. that the list of addresses all correspond to a logically unitary CP and 2. that the admin knows what he's doing. 

> I'm not sure if it makes sense to configure multiple remote addresses for a single destination. It seems to be safer to configure multiple export destinations and to use export member type primary and secondary.
> 
> What do you think?

These are logically separate concepts, and should not be conflated by the data model. Multiple Destinations means multiple CPs: endpoint redundancy, and the assumption is that each Destination is its own CP with separate app-layer state. Multiple addresses means multiple endpoints on a single CP for session setup: _path_ redundancy, and the assumption is that every given address leads to the same CP, with the same app-layer state. Different tools for different situations. Of course you can configure to export to two addresses that aren't the same CP, just like you can configure an EP to export to a destination that _isn't_ a CP. In both cases this is a configuration error.

> As discussed long ago, Templates are not configured. The are created by the Exporting Process depending on the Data Records to be exported.

I'm not convinced this choice is the right one (both the Cache and the EP are valid places to make choices about what, precisely, will be exported: see below the discussion on 

> Therefore, there is no good place for a per-Template reliability parameter in the configuration data model. The only possibility would be to configure the reliability in the Cache, and this would be a very strange place to do it.
> 
> I had discussed this issue with Benoit. The conclusion was that we have a per-Destination parameter. If people want to configure more, they can come up with an extension.
> 

Not really. But now we as a WG are saying logically inconsistent things: I can't reconcile the "templates are applications and the reliability settings are per-application; here is a way to estimate loss across multiple templates to the same destination" view of sctp per stream export and the "destination-level reliability" view presented here. It is an inelegant contradiction.

My personal opinion would be to provide template-level configuration as an EP option in an extension, and to simply ignore this Destination option (much the same way as I work as hard as I can to ignore UDP ;) )

> The idea is that the Exporting Process defines common properties depending on the Data Records to be exported. This can be done dynamically (depending on the value distribution) or using knowledge about the configuration (e.g., if a filter ensures that the accounted packets are from/to a specific endpoint, this can be encoded as common property).
> 
> If you think that reducingRedundancy is not useful, I will remove from the list.

It's certainly useful to have a switch, but we must then be very explicit about the fact that when you turn this switch on, it's up to the EP to determine precisely what redundancy to reduce and how, that this is implementation dependent, and that implementations are encouraged to provide implementation-specific configuration extensions to cover this case.

> Apart from reducingRedundancy, all mentioned Options type appear in the protocol RFCs (RFC5101, RFC5476).

5655 options don't make much sense to configure, as runtime determination and implementation dependency probably dominate there. However, type export as in 5610 seems like it would be a useful configuration switch.

Although this discussion reminds me of another issue I missed, elaborated below.

> Adding more parameter values for optionsType can be easily achieved with YANG extensions because they are specified as identities (it would note be possible with an enum type).

Hm. Okay. Will we create then a "defined Options Template" registry somewhere?

> I do not understand your proposal. There is no Template class for configuration.

I missed this point somehow (perhaps in my assumption that Templates indeed should be configurable, but I did not show up to that discussion so I accept the decision of the rest of the WG)... but yes, indeed, so, withdrawn.

> You can always extend the model. For example, if fragmentation reassembly can be regarded as part of the Cache, you can easily define your own new cacheType (again, identities and identityref in YANG).
> 
> We also have implemented a lot of cool additional functionalities which we are going to configure by extending the model. It is not the purpose of this document to cover all of these.

Indeed. As long as you can collapse these into Cache (which as I said above it seems you can), that's more than sufficient.

> Is reduced size encoding performed by the Cache or by the Exporting Process?

In YAF, there's no process separation, but from a functional block separation this is done in the EP. 

> If you implement a Cache in hardware, it is probably easier to always use the maximum length and to reduce it later in the Exporting Process.
> We assume that the Cache reserves a certain field length for all Data Records in the Cache.  (Variable-length fields are treated differently)

Indeed, I would expect that only caches written in dynamically typed languages, where the language itself autopromotes storage on overflow, would do variable-sized caching of fixed length elements, if only because doing it in C is rather time expensive and difficult for relatively little benefit. And in this case the variable-sized caching is invisible to the programmer.

> The ieLength specifies the field length in the Cache. The length in the exported Data Record can be different. Note again: we are not configuring a Template, here. The exported Data Record may even contain a completely different set of fields, for example in the case of reducing redundancy.

Ah, okay, so it supports it, it just doesn't support configuring it (which can be an implementation dependent extension in either the cache, the EP, or both, which makes sense depending on how it's implemented). This is okay.

>      rules of reduced size encoding are fulfilled (see [RFC5101],

No reason to cut that, as it wasn't the point of confusion...

> Right. I tried to improve this. Please look into my reply to Lothar's review:

Perfect.

> I assume that the URI filename parameter is useful for many FileWriter/Reader implementations.  All additional parameters are probably very specific to the implementation.

Indeed. Okay, makes sense to leave it then, maybe with a statement that the handling of the URI is implementation dependent.

> Uff. I already have problems to convince people that there may be more than one parallel Caches in a Metering Process. Now, you even propose multiple Caches in a series :)
> 
> IMO, aggregation is done in an Intermediate Process, not in a Metering Process and therefore not in the Cache of a Metering Process.
> 
> The configuration of Mediators and Intermediate Process is out of scope of this document. Otherwise, we will never finish...

Accepted. But now I have an idea of at least one subsection heading in the Mediator Configuration Data Model draft :)

> I'm open to concrete suggestions.

Update the text in the configuration model to match that in the MIB, copy the definitions in full from the MIB so you don't have to go read the MIB to figure out what these mean, and call it finished. I expect most people will either find the MIB approach sufficient, or simply leave these parallel and implement their own redundancy.

>> this draft should probably be changed to things "specified" in RFC

And, as promised, a new 11. Cache should have a way to configure biflow assembly and export. The simplest one is simply to state that the presence of reverse Information Elements in a CacheLayout implies that the Cache will assemble biflows suitable for export as described in RFC 5103.

This opens a slightly larger question, though: is this a configuration data model for 5101 and 5102, for all the RFCs published by the WG to date (i.e., adding 5103, 5473, 5610, and maybe 5655), for all the work completed by the WG (adding per-stream), or for all the work accepted aside from mediation (adding flow selection, and possibly anonymisation in a non-mediator context)? I think the last is almost certainly out of scope (otherwise we're never done). Thoughts?

Cheers,

Brian

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 05 Mar 2010 11:49:57 +0100

Hi Brian,

Thanks a lot for your feedback.

Maybe you can have a quick look at my proposals, so that I can close 
these issues (or at least most of them).

Brian Trammell wrote:
>> Data models in network management will never satisfy all people.
>> So, please keep in mind that the goal of this document is to
>> standardize a configuration data model that can be easily
>> implemented by many vendors. There will always be additional
>> vendor-specific parameters, and there will always be
>> vendor-specific restrictions of the model. Thanks to YANG, there
>> are possibilities to make restrictions and extension.
>> 
>> configuration data model can be easily mapped to one of the YAF
>> command line options. Not the other way round.
> 
> Yep, I understand the point of the data model here... and YAF's
> configuration by its nature will most probably remain command-line
> (indeed I was thinking of implementing this in a Ruby script that
> kicked off YAF); the references to YAF herein were merely an attempt
> to use one specific implementation (with which I am familiar) as a
> tool for evaluating the flexibility and general applicability of the
> configuration data model. "This is out of scope" is a perfectly
> reasonable response. bue I wanted to make sure in reviewing that the
> flexibility we can get out of yang is presented in the right way...
> Indeed, in the selector->cache->ep chain, you can probably just model
> intermediate processes (like YAF's partial reassembly) as being part
> of the Cache, and that's just fine.

In an ipfix-mediator-config draft, you can use YANG to extend the model 
to allow  CP->IP->EP  and  OP->SP->Cache->IP->EP  setups.

Speaking in UML, we are not restricted to the existing classes, we 
extend the model by adding new ones.

>> More comments inline.
>> 
>> Gerhard
>> 
>> 
>> Brian Trammell wrote:
>>> Greetings, all, I have reviewed
>>> draft-ietf-ipfix-configuration-model-04 in response to the WGLC,
>>> and have the following comments, ranked in order of impact; most
>>> of these deal with the applicability of the configuration data
>>> model to implementations other than the "exemplar" 
>>>  will say that overall, the draft does an more than reasonable
>>> job of being generally applicable. I apologize for starting a new
>>> thread, but I have not yet had time to properly review other
>>> comments, but plan on being in Anaheim prepared to discuss those
>>> too. I have also explicitly not reviewed the YANG definition; I
>>> leave that to people with actual YANG expertise. First and
>>> foremost is the issue of caches, as it is in cache implementation
>>> that IPFIX packet-to-flow MPs will differentiate the most from
>>> each other, and indeed most vendors should be expected to 
>>>  therefore getting this right is probably the most crucial.
>>> cacheMode immediate seems like a bit of a hack, as it invalidates
>>> basically every other cache field. However, I suppose I can see
>>> it as a way to keep the class design clean (otherwise, there
>>> would be nothing to connect OP to layout/EP in a PSAMP
>>> implementation...).
>> Right.
>> 
>>> 1. I'm concerned about the definition of cacheMode timeout (4.3,
>>> p. 24), as it seems to make it impossible to configure a cache to
>>> allow cache exit on TCP state tracking. Perhaps this is merely an
>>> editorial oversight?
> Basically, yes. Most flow generators will expire a flow after a TCP
> FIN or RST (or some number of these), so there is a difference
> between expiring flows only on timeout and expiring on timeout as
> well as "natural" end of flow (see the definition of flowEndReason,
> IE 136). So I would propose the following:
> 
> values are specified by the configuration data model: *  immediate:
> Data Records expire after the first packet *  timeout: Data Records
> expire after active or inactive timeout |    *  natural: Data Records
> expire after active or inactive timeout, or |       on natural
> termination (e.g. TCP FIN, or TCP RST) as determined |       by the
> Metering Process. *  permanent: Data Records never expire, but are
> periodically exported with interval set by exportInterval In the case
> of "immediate", PSAMP Packet Reports are generated. Otherwise, IPFIX
> Flow Records are generated.

Ok. I change your text as follows (to avoid mentioning Metering Process 
here):

   * natural: Data Records expire after active or inactive timeout, or on
              natural termination (e.g. TCP FIN, or TCP RST) of the Flow

We must be aware of the fact that there are reasons to prematurely 
expire flows (e.g., full cache). I assume that we do not have to mention 
these, do we?

> Alternately, if "timeout" meant "timeout + natural" in this
> terminology, we could change it as follows:
> 
> values are specified by the configuration data model: *  immediate:
> Data Records expire after the first packet |    *  timeout: Data
> Records expire after active or inactive timeout, or |       on
> natural termination (e.g. TCP FIN, or TCP RST) as determined |
> by the Metering Process. *  permanent: Data Records never expire, but
> are periodically exported with interval set by exportInterval In the
> case of "immediate", PSAMP Packet Reports are generated. Otherwise,
> IPFIX Flow Records are generated.
> 
> I'm inclined toward the first alternative, with 'natural' as default
> and 'timeout' provided for MPs that don't want to be bothered with
> TCP state.

Currently, there is no default value. The user must configure the 
cacheMode parameter. I think, this is useful because it forces the user 
to think about what he wants to meter.

>> However, what happens if you configure multiple remote IP addresses
>> and they do not belong to the same SCTP endpoint? What shall the
>> Exporting Process do in this situation?
> 
> "The way the SCTP stack uses the list of addresses to set up the
> association is implementation dependent.  This function only
> specifies that the stack will try to make use of all the addresses in
> the list when needed." The assumptions are 1. that the list of
> addresses all correspond to a logically unitary CP and 2. that the
> admin knows what he's doing.
> 
>> I'm not sure if it makes sense to configure multiple remote
>> addresses for a single destination. It seems to be safer to
>> configure multiple export destinations and to use export member
>> type primary and secondary.
>> 
>> What do you think?
> 
> These are logically separate concepts, and should not be conflated by
> the data model. Multiple Destinations means multiple CPs: endpoint
> redundancy, and the assumption is that each Destination is its own CP
> with separate app-layer state. Multiple addresses means multiple
> endpoints on a single CP for session setup: _path_ redundancy, and
> the assumption is that every given address leads to the same CP, with
> the same app-layer state. Different tools for different situations.
> Of course you can configure to export to two addresses that aren't
> the same CP, just like you can configure an EP to export to a
> destination that _isn't_ a CP. In both cases this is a configuration
> error.

New multiplicity factor for destinationIPAddress:

    +--------------------------------------------------+
    | Destination                                      |
    +--------------------------------------------------+
    | name                                             |<>-----+
    | exportMemberType = parallel                      |       | 0..1
    | ipfixVersion = 10                                |       |
    | transportProtocol                                |   +------------+
    | sourceIpAddress[0..*] {[0..1] for UDP and TCP}   |   | Transport- |
    | destinationIpAddress[1..*] {[1] for UDP and TCP} |   | Layer-     |
    | destinationPort = 4739|4740                      |   | Security   |
    | ifName/ifIndex[0..1]                             |   +------------+
    | sendBufferSize {opt.}                            |
    | rateLimit[0..1]                                  |
    | timedReliability = 0 {SCTP only}                 |
    | numberOfStreams {opt.} {SCTP only}               |
    | templateRefreshTimeout = 600 {UDP only}          |
    | optionsTemplateRefreshTimeout = 600 {UDP only}   |
    | templateRefreshPacket[0..1] {UDP only}           |
    | optionsTemplateRefreshPacket[0..1] {UDP only}    |
    +--------------------------------------------------+

                        Figure 14: Destination class

[...]

    destinationIpAddress:  Destination IP address to which IPFIX Messages
       are sent (i.e., the IP address of the Collector).  This parameter
       MUST be configured by the user.
       If the transport protocol is SCTP, the parameter MAY appear
       multiple times to specify multiple destination IP addresses.  The
       user MUST ensure that all configured IP addresses belong to the
       same Collector.  The Exporting Process tries to establish an SCTP
       association to any of the configured destination IP addresses.

Is this ok?

>> As discussed long ago, Templates are not configured. The are
>> created by the Exporting Process depending on the Data Records to
>> be exported.
> 
> I'm not convinced this choice is the right one (both the Cache and
> the EP are valid places to make choices about what, precisely, will
> be exported: see below the discussion on

Some people think that it is more natural to configure what you want to 
measure, and not how the information is transported to the Collector.

>> parameter in the configuration data model. The only possibility
>> would be to configure the reliability in the Cache, and this would
>> be a very strange place to do it.
>> 
>> I had discussed this issue with Benoit. The conclusion was that we
>> have a per-Destination parameter. If people want to configure more,
>> they can come up with an extension.
>> 
> Not really. But now we as a WG are saying logically inconsistent
> things: I can't reconcile the "templates are applications and the
> reliability settings are per-application; here is a way to estimate
> loss across multiple templates to the same destination" view of sctp
> per stream export and the "destination-level reliability" view
> presented here. It is an inelegant contradiction.

Surely, the parameter must not inhibit the utilization of the 
per-SCTP-stream extension.

Therefore, I changed the parameter description as follows:

    timedReliability:  Lifetime in milliseconds until an IPFIX Message
       containing Data Sets only is "abandoned" due to the timed
       reliability mechanism of PR-SCTP [RFC3758].  If this parameter is
       set to zero, reliable SCTP transport is used for all Data Records.
       Regardless of the value of this parameter, the Exporting Process
       MAY use reliable SCTP transport for Data Sets associated with
       Options Templates.

Ok?

> My personal opinion would be to provide template-level configuration
> as an EP option in an extension, and to simply ignore this
> Destination option (much the same way as I work as hard as I can to
> ignore UDP ;) )
 >
>>> restrictive, even to the point of being unusable. The biggest
>>> problem is that RFC5473 common properties are something
>>> completely different from the options specified in 5101 and 5476.
>>> "Enable common properties", without some definition of which
>>> fields to use as common properties and under what circumstances,
>>> is not a useful directive.
>> dynamically (depending on the value distribution) or using
>> knowledge about the configuration (e.g., if a filter ensures that
>> the accounted packets are from/to a specific endpoint, this can be
>> encoded as common property).
>> 
> It's certainly useful to have a switch, but we must then be very
> explicit about the fact that when you turn this switch on, it's up to
> the EP to determine precisely what redundancy to reduce and how, that
> this is implementation dependent, and that implementations are
> encouraged to provide implementation-specific configuration
> extensions to cover this case.

    reducingRedundancy:  Enables the utilization of Options Templates to
       reduce redundancy in the exported Data Records according to
       [RFC5473].  The Exporting Process decides when to apply these
       Options Templates.

Ok?

>>> Secondarily, options specified in 5610 and 5655 are not covered;
>>> do we really want to amend this document every time we specify
>>> another WG-blessed options template?
> 5655 options don't make much sense to configure, as runtime
> determination and implementation dependency probably dominate there.
> However, type export as in 5610 seems like it would be a useful
> configuration switch.

    extendedTypeInformation:  Export of extended type information for
       enterprise-specific Information Elements used in the exported
       Templates [RFC5610].

Ok?

>> Adding more parameter values for optionsType can be easily achieved
>> with YANG extensions because they are specified as identities (it
>> would note be possible with an enum type).
> 

We could think about this, yes.
At the moment, they are spread over many, many documents.

>>> I'd suggest using an OptionsTemplate subclass of Template,
>>> instead, and providing the definition of common (non-5473)
>>> options templates in an appendix to the configuration data model.
>>> 
> I missed this point somehow (perhaps in my assumption that Templates
> indeed should be configurable, but I did not show up to that
> discussion so I accept the decision of the rest of the WG)... but
> yes, indeed, so, withdrawn.
> 
>>> processes between selection and cache, or cache and EP. The
>>> example that comes to mind is perhaps implementation-specific
>>> [I'm mentioning this because yaf does it]: fragmentation behavior
>>> (reassemble, ignore, drop). How could I allow then for the
>>> configuration of the fragment table (given that a selection
>>> process can only reference a cache)?
>> reassembly can be regarded as part of the Cache, you can easily
>> define your own new cacheType (again, identities and identityref in
>> YANG).
>> 
>> We also have implemented a lot of cool additional functionalities
>> which we are going to configure by extending the model. It is not
>> the purpose of this document to cover all of these.
> 
> Indeed. As long as you can collapse these into Cache (which as I said
> above it seems you can), that's more than sufficient.
> 
>>> 5. CacheLayout (4.3.1, p. 25) does not appear to be able to
>>> support adaptive reduced-length export (exporting, say, counters
>>> with unsigned32 unless one of them actually requires unsigned64)
>>> [yes, yaf does this too]. Though this could probably be solved
>>> with a deviation, and an additional vendor-specific CacheField
>>> attribute...
>> If you implement a Cache in hardware, it is probably easier to
>> always use the maximum length and to reduce it later in the
>> Exporting Process. We assume that the Cache reserves a certain
>> field length for all Data Records in the Cache.  (Variable-length
>> fields are treated differently)
> 
> Indeed, I would expect that only caches written in dynamically typed
> languages, where the language itself autopromotes storage on
> overflow, would do variable-sized caching of fixed length elements,
> if only because doing it in C is rather time expensive and difficult
> for relatively little benefit. And in this case the variable-sized
> caching is invisible to the programmer.
> 
>> The ieLength specifies the field length in the Cache. The length in
>> the exported Data Record can be different. Note again: we are not
>> configuring a Template, here. The exported Data Record may even
>> contain a completely different set of fields, for example in the
>> case of reducing redundancy.
> 
> Ah, okay, so it supports it, it just doesn't support configuring it
> (which can be an implementation dependent extension in either the
> cache, the EP, or both, which makes sense depending on how it's
> implemented). This is okay.
> 
>> For Information Elements of integer and float type, the field
>> length MAY be set to a smaller value than the standard length of
>> the abstract data type if the rules of reduced size encoding are
>> fulfilled (see [RFC5101], Section 6.2).
> 

I want to make this clear. What about the following new paragraph?

    Note that the Data Records generated by the Cache MAY be modified by
    the Exporting Process before sending them to a Collector.  For
    example, the Exporting Process MAY shorten the length of a field
    according to the rules of reduced size encoding [RFC5101].  The
    Exporting Process MAY also export certain fields in a separate Data
    Record as described in [RFC5476].

>>> 6. CacheLayout (4.3.1, p. 25) could do with an explicit example
>>> to illustrate the "unless the corresponding IE is not applicable
>>> or cannot be derived" case: I presume this is intended for
>>> dual-stack IPv4/IPv6 measurement, RFC5103 biflows, and the like?
>>> It does appear than this clause is sufficient for such cases, but
>>> I had to read this a couple of times before I understood that's
>>> what was meant.
>>> 7. Real File Readers and File Writers will probably need more
>>> than a single filename endpoint on the file system (however, most
>>> file readers and file writers in document-based workflows won't
>>> be configured using this information model...) How to handle this
>>> is probably implementation-specific; in any case, I don't have a
>>> good suggestion here, yet; perhaps we can discuss in Anaheim.
> Indeed. Okay, makes sense to leave it then, maybe with a statement
> that the handling of the URI is implementation dependent.

For simple FileWriter/Readers, a single file is enough, and the 
parameter description is clear in this case.

More extended FileWriter/Readers need to extend the model anyway, which 
means that they can also adapt the meaning of the file parameter.

So, rather no further statement which may cause confusion.

>>> processes, or rather, are the benefits of cascading caches
>>> considered in scope for this application? The simplest example
>>> would be simultaneous export of flow data as well as flow
>>> aggregate data (e.g. traffic counters per AS pair), perhaps as
>>> part of a cascading-aggregation mediator. I ask only because it
>>> seems a rather small and easily supportable change to greatly
>>> increase flexibility.
>> Uff. I already have problems to convince people that there may be
>> more than one parallel Caches in a Metering Process. Now, you even
>> propose multiple Caches in a series :)
>> 
>> IMO, aggregation is done in an Intermediate Process, not in a
>> Metering Process and therefore not in the Cache of a Metering
>> Process.
>> 
>> The configuration of Mediators and Intermediate Process is out of
>> scope of this document. Otherwise, we will never finish...
> 
> Accepted. But now I have an idea of at least one subsection heading
> in the Mediator Configuration Data Model draft :)
> 
>>> 9. Destination exportMemberType appears to reference a renamed
>>> MIB object as of MIB-10; this is called ipfixExportMemberType
>>> now. I would suggest copying the complete description from MIB,
>>> because the semantics are kind of confusing otherwise (I had to
>>> read MIB, which I probably should have done by now but oh well,
>>> in order to figure out what the difference between parallel and
>>> primary was). A tertiary problem: these exportMemberTypes seem a
>>> bit restrictive (e.g. what if I want to do parallel export and
>>> also have secondaries?), but I suppose that's a MIB comment.
> Update the text in the configuration model to match that in the MIB,
> copy the definitions in full from the MIB so you don't have to go
> read the MIB to figure out what these mean, and call it finished. I
> expect most people will either find the MIB approach sufficient, or
> simply leave these parallel and implement their own redundancy.

Ok, I will follow your proposal unless I find a better way to configure 
this stuff.

>>> this); since this is now an RFC, references to things "proposed"
>>> in this draft should probably be changed to things "specified" in
>>> RFC 5655.
>> Done.
> 
> And, as promised, a new 11. Cache should have a way to configure
> biflow assembly and export. The simplest one is simply to state that
> the presence of reverse Information Elements in a CacheLayout implies
> that the Cache will assemble biflows suitable for export as described
> in RFC 5103.

Please check the following:

    ieId, ieName, ieEnterpriseNumber:  These parameters specify a field
       by the combination of the Information Element identifier or name,
       and the Information Element enterprise number.  Either ieId or
       ieName MUST be specified.  ieEnterpriseNumber MUST be used for
       enterprise-specific Information Elements.  If ieEnterpriseNumber
       is omitted or zero, this is Information Element is not enterprise-
       specific but registered at IANA.
       If the enterprise number is set to 29305, this field contains a
       Reverse Information Element.  In this case, the Cache MUST
       generate Data Records in accordance to [RFC5103].

[...]

    isFlowKey:  If present, this field is a Flow Key. If the field
       contains a Reverse Information Element, it MUST NOT be configured
       as Flow Key.

> This opens a slightly larger question, though: is this a
> configuration data model for 5101 and 5102, for all the RFCs
> published by the WG to date (i.e., adding 5103, 5473, 5610, and maybe
> 5655), for all the work completed by the WG (adding per-stream), or
> for all the work accepted aside from mediation (adding flow
> selection, and possibly anonymisation in a non-mediator context)? I
> think the last is almost certainly out of scope (otherwise we're
> never done). Thoughts?

For many of the RFC you mention above do not specify any configuration 
requirements. Often, there exist zero to one implementation. So, it is 
difficult to say whether the parameters required by these 
implementations can be assumed to be "common" configuration parameters.

So, I assume, we need more implementations until we can define a 
complete configuration data model for them.

Regards,
Gerhard

---

From: Brian Trammell <[email-masked]>
Date: Fri, 5 Mar 2010 12:55:29 +0100

Hi, Gerhard,

In short, thanks: your proposed changes address all my concerns. As far as I'm concerned, this one's ready to go.

Details inline.

Cheers,

Brian

On Mar 5, 2010, at 11:49 AM, Gerhard Muenz wrote:

> Maybe you can have a quick look at my proposals, so that I can close these issues (or at least most of them).
> 
> 
> Brian Trammell wrote:
>> Hi, Gerhard, all,
> In an ipfix-mediator-config draft, you can use YANG to extend the model to allow  CP->IP->EP  and  OP->SP->Cache->IP->EP  setups.
> 
> Speaking in UML, we are not restricted to the existing classes, we extend the model by adding new ones.

Great. This is okay then.

>>>> model to implementations other than the "exemplar" implementation(s) the authors had in mind while while writing.  I
>>>> each other, and indeed most vendors should be expected to subclass this cache class for their own configuration parameters;
>> cacheMode:  Configures the Cache Mode.  The following parameter values are specified by the configuration data model: *  immediate:
> Ok. I change your text as follows (to avoid mentioning Metering Process here):
> 
> We must be aware of the fact that there are reasons to prematurely expire flows (e.g., full cache). I assume that we do not have to mention these, do we?

You can't very well tell a Cache to go out and buy more storage for itself, now can you? So, no. :)

>> cacheMode:  Configures the Cache Mode.  The following parameter values are specified by the configuration data model: *  immediate:
> Currently, there is no default value. The user must configure the cacheMode parameter. I think, this is useful because it forces the user to think about what he wants to meter.

Yep, makes sense.

>>>> a. can't specify a local IP address for TCP or UDP. This seems necessary on devices with multiple management interfaces, which I
>>> I see send_connectx() in the SCTP API: http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-21#section-8.9

Perfect.

> Some people think that it is more natural to configure what you want to measure, and not how the information is transported to the Collector.

MPs that need to do post-Cache modification can easily extend the model, so no problem.

> Surely, the parameter must not inhibit the utilization of the per-SCTP-stream extension.
> 

Ping Benoit on this one, but it looks good to me.

>>>> 3. Options (4.4.3, p. 30) configuration is rather odd and highly restrictive, even to the point of being unusable. The biggest

Yep.

>      enterprise-specific Information Elements used in the exported

Also yep.

> At the moment, they are spread over many, many documents.

This is probably a good point for a future "what you need to know to nicely extend the protocol" effort...

>>>> 4. There does not seem to be any room for logical configurable processes between selection and cache, or cache and EP. The

Okay, yes; that's better than what's there now.

>>> Right. I tried to improve this. Please look into my reply to
>>> Lothar's review: http://www.ietf.org/mail-archive/web/ipfix/current/msg05325.html
>> Perfect.
> For simple FileWriter/Readers, a single file is enough, and the parameter description is clear in this case.
> 
> More extended FileWriter/Readers need to extend the model anyway, which means that they can also adapt the meaning of the file parameter.
> 

Good. Makes sense.

>>>> 8. Is there any benefit to cascading caches as with selection processes, or rather, are the benefits of cascading caches
>>> Andrew suggested to improve this as well.  See: http://www.ietf.org/mail-archive/web/ipfix/current/msg05323.html I'm open to concrete suggestions.
> Ok, I will follow your proposal unless I find a better way to configure this stuff.
> 
>>>> 10. draft-ietf-ipfix-file is now RFC5655 (the editor will catch this); since this is now an RFC, references to things "proposed"

Perfect. 

> For many of the RFC you mention above do not specify any configuration requirements. Often, there exist zero to one implementation. So, it is difficult to say whether the parameters required by these implementations can be assumed to be "common" configuration parameters.
> 
> So, I assume, we need more implementations until we can define a complete configuration data model for them.

Point. Indeed, as the draft stands with your proposed edits, it covers the protocol as of all applicable RFCs that have options that can be configured: 5101, 5102, 5103, 5473, and 5610, so my question is answered de facto, I suppose.