Subject: [IPFIX] Winding down the ipfix working group.

From: joel jaeggli <[email-masked]>
Date: Fri, 12 Dec 2014 12:05:52 -0800

Greetings,

The chairs and my co-AD and I have decided it's time to window down the
ipfix working group. Our major milestones are completed and we should be
pleased with the results.

We have one remaining active document

draft-ietf-ipfix-mib-variable-export

which I will be happy to AD sponsor. Barring significant commentary to
contrary I will close the working-group on friday december 19th and we
will retain the mailing list for some time after that.

Thanks and congratulations.
Joel

---

From: Paul Aitken <[email-masked]>
Date: Sat, 13 Dec 2014 00:13:20 +0100

Joel, All,

I’m waiting for WG review of draft-ietf-ipfix-mib-variable-export-07
-principally from Brian Trammell and Juergen Schoenwaelder.

P.

From: joel jaeggli <[email-masked]<mailto:[email-masked]>>
Date: 12 December 2014 at 20:05
Subject: [IPFIX] Winding down the ipfix working group.
To: IPFIX Working Group <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Greetings,

_______________________________________________
IPFIX mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Sat, 13 Dec 2014 22:32:07 +0100

hi Paul, all,

AFAIC, I sent in my review on 15 August 2014, edits were made 26 Oct, I followed up 27 Oct. The *document* is basically good to go, I see that there are a couple of outstanding questions from Paul's 30 Oct message; sorry for missing these...

>>>> What the mechanism in the document should _not_ be used for is to expand the IPFIX information model to also include the contents of all the various MIBs, such that SMI IEs could be used alongside IPFIX IEs to export information from non-SNMP sources of data. Otherwise we've created Yet Another Representation for lots of common IEs already in the IPFIX IE registry, which would significantly complicate the comparison and combination of data at collectors. The document needs to make this explicit, either in section 1 or 2.
>>> The mechanism _can_ be used like that.
>> Can be, yes. Is it the express intention of the authors of the draft to do so?
> 
> Authors aside, what does the WG want? Ultimately the goal is to avoid creating new IPFIX IEs for each MIB that needs exported. Does that require considering MIBs as part of the info model?

So I've thought about this a bit and I *think* we agree here: this mechanism exists so that things which are already in MIBs can be exported via IPFIX without having to define new IEs.

Personally, I'd be happy if we didn't start deprecating things already in the native registry in favor of things in MIBs, and if the IE Doctors don't tell someone who wants an IE that they can't have it because it's in MIB X. I don't believe it's necessary to write any of that down though.

>>> Expressed another way, we've already created duplication; now we have to live with it.
>> Actually this seems to be closer to "we've already created duplication, so we can happily create more," which seems dangerous for sustainable interop.
> 
> What change, if any, would you like to see in the draft?

As long as it's clear that the mechanism is intended to glue MIBs to IPFIX, none.

Cheers,

Brian

On 13 Dec 2014, at 00:13, Paul Aitken <[email-masked]> wrote:

> From: joel jaeggli <[email-masked]>
> To: IPFIX Working Group <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> 
> 
> Greetings,
> 
> [email-masked]
> [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 14 Dec 2014 08:46:41 +0000

This WG has done an amazing job. 

Congratulations and thanks to all the participants during the years. 

Regards,

Dan

> -----Original Message-----
> From: IPFIX [mailto:[email-masked]] On Behalf Of joel jaeggli
> Sent: Friday, December 12, 2014 10:06 PM
> To: IPFIX Working Group
> Cc: [email-masked]
> contrary I will close the working-group on friday december 19th and we will
> retain the mailing list for some time after that.
>

---

From: Paul Aitken <[email-masked]>
Date: Mon, 15 Dec 2014 12:22:29 +0100

Brian, please see inline...

Thanks,
P.

> From: Brian Trammell [mailto:[email-masked]]
> Sent: 13 December 2014 21:32
> To: Paul Aitken
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [IPFIX] Winding down the ipfix working group.
> 
> hi Paul, all,
> 
> AFAIC, I sent in my review on 15 August 2014, edits were made 26 Oct, I
> followed up 27 Oct. The *document* is basically good to go, I see that there are
> a couple of outstanding questions from Paul's 30 Oct message; sorry for missing
> these...
> 
>>>>> What the mechanism in the document should _not_ be used for is to
>>>>> expand the IPFIX information model to also include the contents of all the
>>>>> various MIBs, such that SMI IEs could be used alongside IPFIX IEs to export
>>>>> information from non-SNMP sources of data. Otherwise we've created Yet
>>>>> Another Representation for lots of common IEs already in the IPFIX IE registry,
>>>>> which would significantly complicate the comparison and combination of data
>>>>> at collectors. The document needs to make this explicit, either in section 1 or 2.
>> Authors aside, what does the WG want? Ultimately the goal is to avoid
>> creating new IPFIX IEs for each MIB that needs exported. Does that require
>> considering MIBs as part of the info model?
> 
> So I've thought about this a bit and I *think* we agree here: this mechanism
> exists so that things which are already in MIBs can be exported via IPFIX without
> having to define new IEs.

Exactly.

> Personally, I'd be happy if we didn't start deprecating things already in the native
> registry in favor of things in MIBs,

Agreed; this document does not deprecate any existing IEs.

- which means there are now two ways of exporting some things (as IE and as MIB). Collectors should already have architectures which understand this equivalence (effectively a presentation layer) since there are already some equivalent (duplicate) IEs (Andrew Feren had a list), and the list will surely grow as enterprise-specific IEs are transitioned to IANA. So I consider this to be a pre-existing issue which was not introduced by this document.

Therefore I don't see a need to document the existing IE / MIB equivalences in the document. Please shout if you disagree.

> and if the IE Doctors don't tell someone who
> wants an IE that they can't have it because it's in MIB X.

I think it'll be on a case-by-case basis. Hopefully they'll encourage the use of MIB export. However if the use case involves exporting lots of other IEs and no other MIBs, then a new IE would seem justified for simplicity.
Remember that the point of the draft is to avoid overloading the IANA registry with new IEs which are equivalent to existing MIBs.

>  I don't believe it's necessary to write any of that down though.

+1

> As long as it's clear that the mechanism is intended to glue MIBs to IPFIX, none.

Great, thanks!

P.

> > I'm waiting for WG review of draft-ietf-ipfix-mib-variable-export-07
> > The chairs and my co-AD and I have decided it's time to window down
> > the ipfix working group. Our major milestones are completed and we
> > should be pleased with the results.
> >

---

From: Brian Trammell <[email-masked]>
Date: Mon, 15 Dec 2014 12:27:33 +0100

> On 15 Dec 2014, at 12:22, Paul Aitken <[email-masked]> wrote:
> 

Okay, now I get your point. Agreed.

> Therefore I don't see a need to document the existing IE / MIB equivalences in the document. Please shout if you disagree.

At this point I'm happy to leave this as an article for future work should anyone want to pick it up and run with it.

Let's ship it and declare victory (pending Juergen's SNMP-and-MIB-expert review). :)

Cheers,

Brian

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 15 Dec 2014 11:48:31 +0000

As many of you know I have concerns about closing IPFIX.

Whilst IPFIX may have completed sufficient of its work in support
of network management, the protocol has much to offer in terms
of use as a mass data collection protocol particularly in the IOT space.
I thus have some reservations about terminating the work as
opposed to moving it to another area.

- Stewart

---

From: Andrew Feren <[email-masked]>
Date: Mon, 15 Dec 2014 11:57:13 +0000

Are you talking about adding IEs or something more?

If more than just new IEs can you give an example?  I've used IPFIX for transport of more than just network management information. I'm curious what is missing for your use cases.

-Andrew

On Dec 15, 2014, at 6:47 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

- Stewart

-----Original Message-----
From: IPFIX [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Friday, December 12, 2014 10:06 PM
To: IPFIX Working Group
Cc: [email-masked]<mailto:[email-masked]>
Subject: [IPFIX] Winding down the ipfix working group.

Greetings,

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 15 Dec 2014 12:53:35 +0000

On 15/12/2014 11:57, Andrew Feren wrote:
> If more than just new IEs can you give an example?  I've used IPFIX 
> for transport of more than just network management information. I'm 
> curious what is missing for your use cases.
>

Well a bit off the cuff, but how about pre-registered templates rather 
than refreshed templates so that IOT devices don't need to use energy or 
bandwidth to transmit them?

Are there any additional protocol considerations associated with 
privacy, authentication and resilience when IPFIX is used over the wide 
area? For example authenticated data merging?

- Stewart

>>>> Cc: [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Dec 2014 22:39:07 -0800

>> Are you talking about adding IEs or something more?
IE's at least can be handled via expert review. if you needed new one's
for a particular application that work might be best done in connection
with the area of work requiring the IEs (as mibs or information models are).
> than refreshed templates so that IOT devices don't need to use energy
> or bandwidth to transmit them?
>
> privacy, authentication and resilience when IPFIX is used over the
> wide area? For example authenticated data merging?
useful food for thought.

thanks
joel

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Dec 2014 10:06:35 +0100

> or bandwidth to transmit them?
So going back to NetFlow v5? :-)
As you know, we had to move away from v5 to v9 to solve a real problem.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Dec 2014 10:07:16 +0100

Stewart,
> opposed to moving it to another area.
OPSAWG could be used if necessary.

Regards, Benoit

---

From: Paul Aitken <[email-masked]>
Date: Wed, 17 Dec 2014 11:37:01 +0100

Benoit, All,

>> Well a bit off the cuff, but how about pre-registered templates rather than refreshed templates so that IOT devices don't need to use energy or bandwidth to transmit them?
>

Templates generally consume only a tiny portion of the export bandwidth, so they're a non-issue for hard-wired devices in an enterprise or data-centre setting.

However, if a device isn't able to maintain an SCTP or TCP connection (eg because it's a low-power device which exports infrequently and powers down between exports, or it's a mobile device which goes out of range), then the exporter would need to re-send the template at the start of each export. In the worst case the template could be sent with each data record (assuming export over UDP), at which point templates become a significant portion of the export bandwidth. I've seen a packet capture from a device which actually does that.

So I could imagine a use-case where pre-registered templates are useful. The exporter would only send data records, and the collector would have to obtain the necessary template(s) from a repository.

However if the exporter sends the repository URL rather than the template then it's possible that there would be no export saving at all. If the exporter sends a template ID then we'd have to consider how the collector discovers where the repository is located and authentication of the received templates. If it's a central repository then we have to think about authentication for addition of new templates and whether modifications are allowed.

If it was a real use case with actual demand behind it then it could be addressed in one draft which could be AD sponsored. However since it seems to be a theoretical idea with no demand, there seems to be no justification in keeping the WG open just for this.

It could be an interesting NMRG project.

P.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Dec 2014 12:14:54 +0000

On 17/12/2014 10:37, Paul Aitken wrote:
> .
I think my overall point is that IPFIX may have completed it's work as 
an NM protocol, but it has significant potential as a collection 
protocol in other applications. If we give the message that it is in 
maintenance or that we have no IETF interest in further development then 
we know what will happen: a new protocol will be needlessly developed 
from scratch.

With that in mind, mild hibernation might be a better approach. We do 
after all have WG in that state.

Paul understands the application application issue, but I am not 
convinced that a single draft developed in isolation somewhere will 
produce an adequate solution.

In terms of global templates, I would think that a global template ID of 
32bits, extensible in 32bit quanta to 128 bits would suffice for a while.

Stewart