Subject: Re: [IPFIX] draft-claise-structured-data-in-ipfix-01

From: Atsushi Kobayashi <[email-masked]>
Date: Mon, 27 Jul 2009 20:06:26 +0900

Dear Benoit and all,

I send it to IPFIX only.
Several examples bring the motivation of structured data.
However, I come up with a question during going through this draft.

- Is IPFIX version kept, even if the IPFIX extension installed?
This extension can provide new exporting method regarding multicast 
outgoing interfaces, MPLS stacks, and Packet Selection Sequence Report
Interpretation. An Exporter can choose two methods regardless of
Collector side implementation. A Collector complying with only RFC5101
cannot decode all of data. 

Regards,
Atsushi

On Fri, 26 Jun 2009 14:43:14 +0200
Benoit Claise <[email-masked]> wrote:

> Dear all,
> 
> A new version of the IPFIX structured is in the process of being posted 
> (manual post requested)
> Note: as requested by Dan in the OPS-AREA meeting minutes, I'll include 
> OPS-AREA in the email
> 
> Most of the points discussed during both the IPFIX and OPS-AREA meetings 
> were addressed.
> - more justifications why we need this structured data type and why 
> appropriate protocols are not suitable
> - less focus on security. More example related to IPFIX, such as list of 
> interfaces in a multicast flow, such as the MPLS label stack entry,
> - discussion about the recursive structured data
> - connection with the current IPFIX mediation function work.
> - connection with the one-way delay export, specified in PSAMP
> - Example of an aggregated observation point in a mediation function, 
> which might be needed as a scope in an options template record
> - etc...
> 
> As always, your feedback is welcome
> 
> Regards, Benoit.
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

-- 
Atsushi Kobayashi <[email-masked]>

---

From: Paul Aitken <[email-masked]>
Date: Mon, 27 Jul 2009 12:32:37 +0100

Atsushi-san,

> - Is IPFIX version kept, even if the IPFIX extension installed?

I believe the IPFIX version should not be changed, because the protocol 
has only been extended a little rather than being substantially changed.

> cannot decode all of data.

However it can skip over the data - which is the usual IPFIX model: if 
you cannot read something, at least you can move on to the following 
information.

Even if the IPFIX version was changed, the collector would still be 
unable to decode the data.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 27 Jul 2009 13:53:29 +0200

hi, Paul, all,

I concur; version 11 should be reserved for framing changes, not  
information model changes. By framing these structures within IEs, we  
get to use them without defining a new version.

However, we might want to include in this effort 1. an identification  
of all IEs in the information model at publication time which are  
clear "kludges" (mainly here I mean the MPLS label stack), and 2.  
creation of IEs to cover these cases within the structured data IEs,  
if necessary. This document should also note that EPs supporting  
export of information using structured data for these cases SHOULD  
provide configuration to disable them and use the old methods for  
interoperability.

Regards,

Brian

On Jul 27, 2009, at 1:32 PM, Paul Aitken wrote:

> I believe the IPFIX version should not be changed, because the  
> protocol has only been extended a little rather than being  
> substantially changed.
>
>
> However it can skip over the data - which is the usual IPFIX model:  
> if you cannot read something, at least you can move on to the  
> following information.
>

---

From: Atsushi Kobayashi <[email-masked]>
Date: Mon, 27 Jul 2009 21:25:31 +0900

Hi Brian and Paul,

On Mon, 27 Jul 2009 13:53:29 +0200

> provide configuration to disable them and use the old methods for  

I agree. It resolves my question.

Regards,
Atsushi