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

[Brian Trammell <[e-mail]>]

Hi, Gerhard, all,

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

> 
> 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.

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.

> 
> 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?

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.


> 
>> 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.
> 
> This will be fixed as proposed in this mail unless anybody objects:
> http://www.ietf.org/mail-archive/web/ipfix/current/msg05316.html

Perfect.

>> b. can't specify 1..n remote IP addresses for SCTP. This breaks one
>> 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?

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.

>> c. can't configure SCTP reliability per-template, as opposed to per
>> destination. see 2.b.
> 
> 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.
> 
> If you have another convincing solution, please let me know.

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 ;) )

>> 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.

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.

>> 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).

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'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.

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.

>> 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.

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...
> 
> 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.

> 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).

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

> 
>> 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

Perfect.

>> 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.

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

> 
>> 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...

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.
> 
> 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.

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.

>> 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.

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