Subject: [ipfix-arch] RE: IPFIX Architecture

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 6 Feb 2002 18:47:17 -0800

Hello Ganesh/Folks 

my comments to Ganesh's comments. 

G: 
   Is the intention to make "capability negotiation" a MUST?
   IMHO  the collector should accept whatever is 
   being exporterd by the exporter. In most of the cases (atleast 
   from a router point of view)  the collector is only an 
   intermediate box between the exporter and the final node that
   interprets the export information. The job of the collector
   from an information point of view would just be to grab all
   that the exporter sends.
   From an export protocol perspective, maybe it would make sense to
   do some kind of negotiation. But here also with so much of 
   infrastructure existing already for reliability, security
   etc the question is whether we want to come with a new model
   or just concentrate on flow export.IMO there is no need for
   negotiation.
G: 

[Reinaldo] I basically disagree with this (and not because I wrote the
capabilities section(;-)). Capability negotiation is very important part of
the process. The capability negotiation will negotiate the use existing
protocols and methods, not new ones.

More specifically "In most of the cases (atleast 
   from a router point of view)  the collector is only an 
   intermediate box between the exporter and the final node that
   interprets the export information. "

I disagree. Are you talking about some specific implementation?

And saying that he job of the collector from an information point of view
would just be to grab all that the exporter sends it's not totally true.
Maybe I want to use encryption, maybe I want to use TCP instead of SCTP,
maybe I want to export overlapping flows..I do not want to send data that is
not going to be useful or cannot be decoded properly. Maybe you have an
specific implementaion in mind. 

G:
The underlying transport or other protocol is something which can be
configured by the sys. admin., whatever the way he wants: 
CLI, SNMP, telnet, ...
G:

[Reinaldo] huh? Again, are you talking about a specific implementation? I
can expand this argument and say that everything can be configured by the
sys.admin. This is hardly an argument.

G:
Fail-back is not possible on a router -> too much memory needed.
The best we can do is fail-over.
G:

[Reinaldo] huh? Again, are you talking about some special implemetation? The
word impossible I usually reserve for eternal life and not paying taxes (;-)

G: 
"  -  Receiving IPFIX user messages according to a decoding scheme, 
  checking message integrity, and acknowledging it after it is 
  correctly received or optionally processed and persisted in storage. "

I feel this should be taken care of by the lower layers. 
G: 

[Reinaldo] yep, I kind of agree with that, except that the collector is the
only that can check for error on the IPfix protocol itself.

G:
If we have the timestamp per flow why is resequencing required
G:

[Reinaldo] humm...I need to think more about this one...

G:
   If the reliability is guarenteed by the network, is there a necessity
   for a reliable transport? As we explained in IETF-52, there are 
   scalability concerns with TCP and making this mandartory would
   exclude the exporters with high volume from being IPFIX compliant.
G: 

[Reinaldo] I think saying that realiability might not be needed if is
guaranteed by the network is a fair statement.

But as Van Jacobson pointed out in your presentation, saying that TCP has
anything to do with high volume, that's not the case. Any protocol that need
to provide a similar functionality (congestion control, retransmission,
windowing, etc) will have the same problem. He also pointed out some
scalability issues in your server due to internal memory copyingy.

So my point is that if you have a high volume server over a unrealible
network and you use UDP as a transport, the IPfix protocol will need to
provide TCP-like functionalities and you will have the *some* of the issues
you mentioned.

G:
   Why all these are mandatory for IPFIX layer. I agree the framework
   should take care of this. But if there is a capability already
   available why re-invent?
G: 

[Reinaldo] yep,I agree with this.

G: 
   The message should have the follwoing
   - sequence number if the collector wishes to sequence the packets.
G: 

[Reinaldo]. Again, are you talking about a specific implementation? I could
use your own argument and say that this can be provided by the lower layers
(TCP or SCTP). This is only a requirement for UDP.

G: 
   Templates can be exchanged at any time. This may be done
   as a result of a config change in the exporter or it may be a
   periodic update.
G: 

[Reinaldo] Agreed, this is in the capability negotiation.

G:
In short the fundamental aspects of disagreement are:
- no template/capabilities/etc... negotiation in IPFIX
- no MUST for reliable
- no state information (except based on the transport protocol, if
connection oriented)
- no connection initiated from the collector.
G:

[Reinaldo] I disagree with the first, I kind of disagree with the second,
and agree with the third in terms that the connection can be initiated from
both sides.

regards,

Reinaldo

---

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 06 Feb 2002 20:05:44 -0800

Hi Reinaldo,
  See my responses inline  starting with [G].
Thanks
Ganesh

Hello Ganesh/Folks

G:

[Reinaldo] I basically disagree with this (and not because I wrote the
capabilities section(;-)). Capability negotiation is very
important part of the process. The capability negotiation will negotiate
the use existing protocols and methods, not new ones.

[G] The existing protocols can be pre-setup in the exporter and
collector by the administrator.
There is whole suite of actions that needs to be done if one were to
negotiate this operation.
There is transport (TCP/SCTP/UDP), network layer (V4/V6),  maybe lower
layers like
MPLS, methods of authentication, security (ipsec, TCP MD5), etc. Yes we
can build
an automated system which detects all these narrows to the least common
denominator,
sets up all these stacks and performs the export. But I do not see
anything extra we can
achieve other than the added complexity. It This is not like a data link
protocol where one
expects to negotiate and see the link up when a cable is plugged.

[G] No. A collection device is usually attached to multiple routers (I
do not know about probes)
There are some things like more aggregation that happens in the
collector.
This data gets fed  into analyzers which perform the final analysis.

And saying that he job of the collector from an information point of
view would just be to grab all that the exporter sends it's
not totally true. Maybe I want to use encryption, maybe I want to use
TCP instead of SCTP, maybe I want to export overlapping
flows..I do not want to send data that is not going to be useful or
cannot be decoded properly. Maybe you have an specific
implementaion in mind.

[G] You can decide this by configuring the exporter to send only what is
required.

G:

[Reinaldo] huh? Again, are you talking about a specific implementation?
I can expand this argument and say that everything
can be configured by the sys.admin. This is hardly an argument.

G:

[Reinaldo] huh? Again, are you talking about some special implemetation?
The word impossible I usually reserve for eternal life
and not paying taxes (;-)

[G] I take back my statement. I was not sure of fail-back & fail-over.

G:

[Reinaldo] yep, I kind of agree with that, except that the collector is
the only that can check for error on the IPfix protocol itself.

G:

G:

But as Van Jacobson pointed out in your presentation, saying that TCP
has anything to do with high volume, that's not the
case. Any protocol that need to provide a similar functionality
(congestion control, retransmission, windowing, etc) will have
the same problem. He also pointed out some scalability issues in your
server due to internal memory copyingy.

[G] Memory copy is only one issue. The memory buffering requirement to
take care of
even a single retransmission for high bandwidth router spans 10s to 100s
of Megabytes.
So TCP is out of question.
In a network with reliability why add more task to the router processor
by
putting TCP?

So my point is that if you have a high volume server over a unrealible
network and you use UDP as a transport, the IPfix
protocol will need to provide TCP-like functionalities and you will have
the *some* of the issues you mentioned.

G:

G:

[Reinaldo]. Again, are you talking about a specific implementation? I
could use your own argument and say that this can be
provided by the lower layers (TCP or SCTP). This is only a requirement
for UDP.

[G] This would help to have a consistent implementation across transport
protocols.

G:

[G] I did not mean the negotiation part:) The exporter sends collector
the template format.

G:

[Reinaldo] I disagree with the first, I kind of disagree with the
second, and agree with the third in terms that the connection can
be initiated from both sides.

regards,

Reinaldo

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: "Reinaldo Penno"<[email-masked]>
Date: Thu, 7 Feb 2002 09:24:41 -0800

David,
 
what you are proposing is very difficult to be done, because when we are
architecting this "box" we need to know what the lower layers can or cannot
provide us. So, should we put a sequence number on the header? Should we
provide ack fields? etc, etc...
 
Other comments inline...

-----Original Message-----
From: Harrington, David [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 6:21 AM
To: [email-masked]
Subject: RE: [ipfix-arch] RE: IPFIX Architecture

Hi,
 
I've seen working group after working group get hung up on the lower-level
transport layer issues with TCP versus UDP versus SCTP.
 
I recommend that IPFIX take the modular approach - identify a transport
"box" in the architecture, then use a separate document to specify different
possible transport mappings, and the specifics of things like retries can be
described in the transport mapping document. Defining the fact that there is
a box to handle transport issues let's the rest of the work continue without
everything being dependent on the resolution of the transport issue.
 
I strongly recommend keeping the transport parameters out of the IPFIX
message. The IPFIX message should be consistent no matter which transport is
being used. Having lots of "optional" or conditional things in the IPFIX
message will make it dramatically harder for the two ends of a communication
to interoperate in a useful manner.  
 
I can't follow this line of reasoning. I gave examples of several protocols
that use capability negotiation and there is no problem. 
 
*Actually, it's the capability negotiation that makes them interoperable*.
 
Can you imagine PPP without LCP? Or nowadays for that matter BGP without
capabilites negotiation? Or even OSPF.
 
The goal is to set a "standard" so behavior is consistent and each side
knows how to do their part of the job. It can be a good thing to favor
flexibility over rigidity in software development, but standards development
is slightly different than software development, and the primary goal should
be interoperability 
 
oops. Hold on. IETF is about rough consensus and *running code*. We are not
doing paper exercise here. Eventually the standards will need to be coded
and vendors will (as always) want to make their extensions for whatever
purposes (customers, edge over the competition, etc). A protocol should be
extensible.
 
  - that requires clearly defining the expectations. It is a GOOD thing to
make the standard "rigid" so there is interoperability.  
 
being flexible has nothing to do with lack of interoperability. 
 
regards,
 
Reinaldo 
 
dbh

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 2:35 AM
To: [email-masked]; Ganesh Sadasivan
Cc: [email-masked]
Subject: RE: [ipfix-arch] RE: IPFIX Architecture

Hello Will,
 
first of all I would like to say that  I do not think some of the stuff
proposed by Ganesh/You is the right approach. I'm not saying Netflow is good
or bad, I'm just do not think is the right think to do, no more no less. 
 
If you give me consistent arguments I can easily be convinced otherwise.
Other comments inline.
 
 ----Original Message-----
From: Will Eatherton [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 9:31 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan
Cc: [email-masked]
Subject: RE: [ipfix-arch] RE: IPFIX Architecture
Reinaldo,

The notation for who is speaking in this thread is making me dizzy, but I
would like to state in a different way what Ganesh is saying on the main
topic of this thread.  For the application of router export to a collector
we are saying that allowing UDP without required capability negotiation (as
an option) is important. 
 
why is important? 
 
1. As I said, you exchange a mere few packets and both ends agree that
Netflow will be the IPfix protocol (or LFAP, or Diameter, or whatever) and
you are done. What you are trying to propose is to make the IETF protocol
rigid under the "using experience gained from widely deployed protocols "
umbrella in order to fit an already deployed protocol of a single vendor.
Unfortunaltely I do not agree with that. 
 
2. Ganesh also mentioned that this is data link stuff, which I said it
wasn't true since BGP implements a similar mechanism (BTW proposed by
Cisco). 
 
3. Then he said we should have sequence number on the IPfix protocol under
the "would help to have a consistent implementation across 
transport " umbrella. My argument is that this is something to solve a
specific UDP related problem only, and unless there is a better reason then
the one above, no matter how you slide or dice it, we are wasting header
space. 
 
Also I don't understand the desire in this thread to dance tip-toe around
the fact that there is already a widely deployed export protocol used in the
application of routers export and we (in this case Ganesh) are giving you
the feedback based on experience one vendor has gained from experience with
that protocol.   
 
And I agreed to some of these stuff ! But unfortunately some of other
feedback is biased to how Netflow is implemented. As i said, I just do not
think some of the stuff proposed by Ganesh/You is the right thing to do, no
more no less. 
 
 We are seeing capability negotiation as complex  
 
why it's complex? You have similar functionality already working for BGP
today. You also have similar functionality working for PPP and OSPF also
today.

 , not a requirement, and are suggesting it should not be a MUST for IPFIX
unless it isnt the goal of IPFIX to be implemented on routers (is it a probe
spec only ?).  
 
huh? Anyway, I think what I'm proposing is fair for everybody since several
protocols can fullfill the IPfix requirements (Netflow, LFAP, CRANE,
Diameter).and make the negotiation phase independent of the protocol used
for the data flow.
 
regards,
 
Reinaldo

---

From: "Reinaldo Penno"<[email-masked]>
Date: Thu, 7 Feb 2002 15:55:58 -0800

Sorry, what I meant is <I'm NOT embedding them into IPfix data flow.>
 
regards,
 
Reinaldo

-----Original Message-----
From: Penno, Reinaldo [SC9:T327:EXCH] 
Sent: Thursday, February 07, 2002 3:30 PM
To: Ganesh Sadasivan
Cc: [email-masked]; [email-masked]
Subject: RE: [ipfix-arch] RE: IPFIX Architecture

-----Original Message-----
From: Ganesh Sadasivan [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 2:09 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: [email-masked]; [email-masked]
Subject: Re: [ipfix-arch] RE: IPFIX Architecture

1. Embedding a set of  protocols (netflow, crane, lfap) into IPFIX is 
    a bad idea.  
 
Nope, I'm embeding them into IPfix. Please refer to my write up.
 
 There is nothing that we achieve out of this. One might 
   as well use just the protocol and not IPFIX. A box usually would 
   adopt only one export protocol and if it knows the collector there is 
   no need for an IPFIX framework.  
 
 2 . Automatically finding which transport one need to send on is only one 
   small piece of information to setup the connection. One has to know 
   the dst port to send on, TCP options like MD5 etc which needs to 
  be configured at both ends anyways. Adding another piece of CLI or 
  so to tell use TCP/UDP/. is much more simpler than creating a negotiation 
  to do this. I really fail to understand what you gain in this whole
process 
  of negotiating transport and such rather than the added complexity!!  
 
So, why people did it for BGP, PPP, OSPF and others? Why not configure
everything by hand? Why we have IKE? Why not pay someone to type in all keys
in worlds in a on-demand basis everytime two systems want to use IPsec. 
 
Well, we do not even need networks. We just need big printers, truck loads
of papers and  a priority account with Federal Express.
  
3. "Negotiation" is a multistep process where 2 sides try to converge 
   as "advertisement" is just a  broadcast of capabilities.  
 
humpf...I'm not even going to comments on that. This seems to me a desperate
argument. 
 
 At this point I wish someone else from the list also raised 
their opinion on this topic rather than we 2 debating with each other. 
Nevil, Dave, do you guys have any suggestions? 

Thanks 
Ganesh 

Reinaldo Penno wrote: 

 Hello Ganesh,please refer to my comments. 

-----Original Message----- 
From: Ganesh Sadasivan [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, February 07, 2002 11:22 AM 
To: Penno, Reinaldo [SC9:T327:EXCH] 
Cc: [email-masked]; [email-masked] 
Subject: Re: [ipfix-arch] RE: IPFIX Architecture 
 
Hello Reinaldo, 
   BGP does advertisements and not negotiation. The neighbours settle down
for 
   the least common set of advertised fields. oh Come on man (;-). That's
dictionary play. It does capability negotiation through "advertisements"
since in the BGP world peers send "advertisements" to each other. If you
look at http://www.ietf.org/rfc/rfc2842.txt
<http://www.ietf.org/rfc/rfc2842.txt>  it's going to be clear that they want
to settle down on a set of common optional parameters. You can call this
something else, I call it capability negotiation, but the purpose is the
same. 
  
 But the most important point is that 
   only the attributes that pertain to the BGP are negotiated and nothing
outside its 
   framework like transport connection, authentication (TCP MD5) etc. okay.
So if we settle down that, for instance, UDP is the protocol of choice then
we do not need to negotiate that. But if we do not settle for that, we need
something to tell me what's going to be the transport protocol since I do
not want to understand/icode/nterpret headers that I'm think are not useful
if, for instance, I implemented with TCP.Also, I'm not advocating
negotiating TCP options and things like that, it's only the transport
protocol used. Any TCP options are done through TCP itself. The idea of CN
is that in a heterogeneous network you only need to configure what the peers
are, you do not need to say "ohh this is anetflow collector", this is a
"CRANE exporter", "this is a IPfix v1 exporter", etc.okay, let me backtrack
a little bit. did you read my capability negotiation write up?  I proposed
it as a totally different phase disconnect to any data flow. After the
capability negotiation is done the connection is teared down and the
protocol of choice gets to work.  
  They are configured in the neighbours  instead. 
   Extending this to IPFIX framework, the only set of attribs that may need
negotiation is 
   templates and this too is optional. There are other parameters, please
refer to the write up. Wouldn't be nice that instead of configuring netflow
v1, v5, v9, etc to have this done automatically and knowing why it worked or
not? What I'm proposing is a control communication completely orthogonal to
the data communication. You do not need to change, for instance, netflow at
all.  It's not built in on the protocol like BGP.thanks,ReinaldoAtleast in
router case I do not see a need to do this. 
   BGP peers are not discovered or auto negotiated. They are configured
instead. 
   Negotiation is a great idea. But one has to look at the practical aspects
also:) Thanks 
Ganesh

---

From: "Reinaldo Penno"<[email-masked]>
Date: Thu, 7 Feb 2002 17:10:40 -0800

Hello Ganesh,

-----Original Message-----
From: Ganesh Sadasivan [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 4:23 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: [email-masked]; [email-masked]
Subject: Re: [ipfix-arch] RE: IPFIX Architecture

1. That's what I would say to you. Read your own draft before 
    jumping into conclusion. 
2. The way  BGP and OSPF does their advertisment is very different 
    from your proposal. Please read the respective RFCs for clarification. 
    Compare that with your proposal and you can find what the diff. is 
    between "negotiation" and "advertisement". 

I call this whole process negotiation. 

It's a "multistep" process as you like to call it. 

1. peer A send OPEN message, 

2. Peer B first determines if it supports capability negotiation. 

3. If yes,  it analyzes capabilities received and determine if they are
acceptable. 

4. If they are acceptable they proceed with the connection, 

5. Otherwise Peer B sends a NOTIFICATION message including the offending
optional capability. 

6. Peer A  receives the NOTIFICATION message and terminate the connection.
It might retry to establish the connection later without this optional
parameter. 

This interaction may happen several times. If this is not negotiation I do
not know what this is. 

regards, 

Reinaldo

---

From: Benoit Claise <[email-masked]>
Date: Fri, 8 Feb 2002 10:32:33 +0100 (CET)

Kevin,

My comments insides.

Regards, Benoit.

> 
> Hi Benoit,
> 
> Please see my answers to some of your concerns.  Thanks,
> 
> Kevin
> 
> > From: majordomo listserver [mailto:[email-masked]]On Behalf
> > Of Benoit Claise
> > Sent: Wednesday, February 06, 2002 5:43 PM
> > To: [email-masked]
> > Cc: Ganesh Sadasivan; KC' 'Norseth; [email-masked]
> > Subject: Re: [ipfix-arch] Re: IPFIX Architecture
> > 
> > 
> > Hi Kevin,
> > 
> > A couple of important points I would like to discuss amongst the 
> > group [I haven't copied the entire document]
> > G: stands for Ganesh
> > Kz: Kevin Zhang
> > Ben: Benoit
> > 
> > G:
> > [kz3] What you are saying is correct.  It depends on whether you 
> > want to do it in-band within the export protocol or
> > out-band.  However, do it within the protocol improves 
> > interoperability significantly which is exactly this WG is
> > trying to achieve.
> > [kz]
> > 
> > [Ben] I don't know how it improves the interoperability to do the 
> > configuration inband.
> > IPFIX stands for Flow Information eXport. So we have to 
> > standardize the export, not the configuration. So the
> > direction:exporter -> collector and not the direction collector 
> > -> exporter. At least not for the configuration.
> > Standardizing the configuration is a huge job. Do you think that 
> > vendors will spend time and money to developp again
> > another configuration interface, next to CLI, SNMP, XML, etc...? 
> > And this just for an IPFIX protocol!
> > What I'm thinking is that the configuration of the probe or the 
> > router is out of the scope of this document and is
> > based on proprietary solutions. Proprietary solutions that you 
> > will very hardly standardize, because they all
> > contains different proprietary features.
> > [Ben]
> > 
> [kz] Our objective is to achieve high interoperability through hopefully minimum standardization.  Especially when multiple existing exporting protocols exist, we need to make both end-points aware of what protocol to use and what version to use, etc.  By standarding the capability negotiation, both end-points can select the exporting mechanism they want to use.  Otherwise, to achieve interoperability, we need to standardize a export protocol (e.g. Netflow, CRANE, LFAP, or Diameter), I am skeptical that the group will ever agree on one of them.
> [kz]

[Ben]
I'm confused by your approach!
You said: "Our objective is to achieve high interoperability..."
But interoperability of what? You speak of multiple existing exporting protocols, what protocol/version to use...
The goal is to have one new IPFIX protocol and not a collector that can once select Crane with a specific exporter, LFAP with another, IPFIX with a third one, Netflow with a four one, etc...
If you speak of interoperability of IPFIX versions, we haven't yet started to agree on version 1. But if we all agree and do it right, I just hope that only the Information Model will evolve along the time, not the protocol
If you speak of interoperability of different vendors, then I agree.

And to come back to your initial statement of this thread: in-band provisioning of a IPFIX exporter improves interopability. I'm still not convinced at all.

> 
> > 
> > [kz2] "capability negotiation" is a MUST, this is key for the 
> > IPFIX system to be flexible enough to deal with various
> > exporting devices (besides core routers).  Your view is 
> > router-centric, at least in a probes case, what to collect,
> > how to collect, and when to export are typically configurable by 
> > the applications through the collector.
> > Furthermore, exactly due to the existing infrastructure, 
> > "capability negotiation" would be key for the exporter and
> > collector to understand what are the lower layer support (e.g. 
> > security, transport protocol, etc.) for the interace.
> > [kz]
> > 
> > [Ben] Well, I guess that I have a "router-centric" view as you call it ;)
> > As I expressed before, my view is that, because the exporter 
> > configuration must happen out-of-band, capabilities
> > negotiation should not happen.
> > 
> > 1. Neither capabilities negotiation for the exported fields in a template:
> > because the template is based on what the exporter can do, not on 
> > what a collector thinks an exporter can do.
> > In other words, you configure the exporter template (by whatever 
> > means), the transport protocol and where to export.
> > Then the collector must be able to parse all the fields of the template.
> > I refer you to section 8 of 
> > http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-
> > 00.txt for more details
> > of what I'm thinking.
> > 
> > 2. Neither transport protocol negotiation.
> > The transport protocol is the first thing you will decide on in 
> > an accounting network design (accouting being just a
> > generic term).
> > I mean, depending if you want to be billing or traffic 
> > monitoring, you may use a connection-oriented transport
> > compared to UDP, with or without IPSEC.
> > Basically, you won't change very often your transport protocol.
> > So why would like to invest time in a transport protocol negotiation?
> > I would say that this would be configured once for all before you 
> > even start exporting the first flow record.
> > [Ben]
> > 
> [kz] What to export should be determined jointly by the exporter and collector based upon end applications requirement and exporter's limitation.  This is important if the exporter is a probe, the end application may only interested in some aspect of the flow information. "Capability negotiaton" allow you to achieve that.  Transport layer negotiation is primarily reserved to accommadate future technologies, e.g. SCTP.  
> [kz]

[Ben]
I agree till:
"What to export should be determined jointly by the exporter and collector based upon end applications requirement and exporter's limitation.  This is important if the exporter is a probe, the end application may only interested in some aspect of the flow information."
But you don't need a negotiation between the collector/exporter for that. I just call that provisioning. You want the Src IP address in your application, fine! You just configure it on the exporter. If you want your collector to do it, fine, but:
- you don't need a negotiation for that
- don't do the provisioning in-band (see the thread #1 above)

And for transport protocol negotiation, I can't add more than David Harrington in his email:
"I strongly recommend keeping the transport parameters out of the IPFIX
message. The IPFIX message should be consistent no matter which transport is
being used. Having lots of "optional" or conditional things in the IPFIX
message will make it dramatically harder for the two ends of a communication
to interoperate in a useful manner. 
 
The goal is to set a "standard" so behavior is consistent and each side
knows how to do their part of the job. It can be a good thing to favor
flexibility over rigidity in software development, but standards development
is slightly different than software development, and the primary goal should
be interoperability - that requires clearly defining the expectations. It is
a GOOD thing to make the standard "rigid" so there is interoperability."

This email contains a lot of common sense.

> > [kz6] I don't see big difference for memory requirement between 
> > fail-over and fail-back, would you please providing
> > more details?
> > [kz]
> > 
> > [Ben]
> > Fail-over means that as soon as you detect that the connection 
> > (only in case of a reliable transport protocol, not
> > UDP) to the collector is lost, you can start sending to another 
> > collector. You may loose a few flow records depending
> > on your transport protocol keepalive.
> > Fail-back means that if we switch to another collection, we can' 
> > t loose any data.
> > Again maybe a router-centric view ;), but Ganesh showed at the 
> > last IETF how much data we can produce per second when
> > exporting from a router.
> > 
> > I refer you to section 4.1.3 and 4.2.3 of 
> > http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt
> > for more details of what I'm thinking.
> >     4      Flow Export Protocol  ...................................   9
> >     4.1    Simple Export Model  ....................................  10
> >     4.1.1  Collector Crash  ........................................  10
> >     4.1.2  Collector Redundancy  ...................................  10
> >     4.1.3  Collector Failover  .....................................  10
> >     4.2    Export Model with Reliable Control Connection  ..........  10
> >     4.2.1  Collector Crash  ........................................  11
> >     4.2.2  Collector Redundancy  ...................................  11
> >     4.2.3  Collector Failover  .....................................  12
> > [Ben]
> > 
> [kz] I understand your concerns. [kz]
> 
> 
> > 
> >   -  Re-sequencing the received IP flow information if required. In
> >   case a reliable, in-sequence delivery service is provided by lower
> >   layer protocol, this function can be omitted.
> > G:
> > [kz7] Timestamp is not sufficient to detect message losses, 
> > particularly when unreliable transport protocol is used.
> > [kz]
> > 
> > [Ben]
> > Right, but you can still have a sequence ID in the packet which 
> > will tell you if you are loosing some packets.
> > Is this what you have in mind when talking about re-sequencing?
> > 
> > Regards, Benoit
> > [Ben]
> > 
> [kz] I think it's possible to include both sequence number and Timestamp in a user message [kz]

This is what has been done in our proposal draft. 

Regards, Benoit.