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

[Gerhard Muenz <[e-mail]>]

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

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

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

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.

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

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?


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

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.

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

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

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

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

Ok?

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

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

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

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.

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

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


> 
> Cheers,
> 
> Brian

-- 
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:  [phone]       Fax: [phone]
E-mail: [e-mail]    WWW: http://www.net.in.tum.de/~muenz