Subject: [ipfix-protocol] RE: info model flexibility

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Wed, 4 May 2005 18:56:01 +0200

Dear Benoit,

Currently downcasting is a property of the protocol. To give flexibility to new Information Elements definition it must be an Information Element property. In the following example foo definition says that it can be downcasted as B and C. That is not feasible currently because downcasting is hardcoded in the protocol.

Name:                          foo

Description:                 ""

Abstract Data Type:      A

ElementId:                    555

Dowcasting:                 B and C

There is another benefit to define downcasting in the info model: It will be possible to limit downcasting to a subset of integer (e.g. unsigned64 to unsigned32 only instead of unsigned64 to unsigned32 or to unsigned16 or to octet).

Regards

Emile

________________________________

De : Benoit Claise [mailto:[email-masked]] 
Envoyé : mercredi 4 mai 2005 16:32
À : STEPHAN Emile RD-CORE-LAN
Cc : [email-masked]; Juergen Quittek
Objet : Re: info model flexibility

Hi Emile,

Hi Benoit,

The info model (section 2.1) is designed to be managed dynamically by IANA without moving to a new protocol version. So I consider that more flexibility must be given to the specification of Information Elements in the info model. Let's take a real example:

Downcasting is currently defined in the protocol specification. Consequently it will not be possible to use them in the future with new field types. 

I don't understand why?

So Downcasting may be moved in the section 2.1 of the info model.

The agreement was that the I.E. must define its maximum length. This was required by the database guys who wanted to be able to define their schemas.
If an exporter doesn't have to use the full length, why export it? This is a protocol issue and not an information model issue. 

What about replacing "dataType - One of the types listed in section 3.1 of this document..." with" dataType - Types listed in section 3.1 of this document..." ?

I don't get the point with the more flexibility argument.

Or what about defining a downcasting keyword in the MAY list of this section?

See above.

Regards, Benoit.

Regards

Emile

________________________________

De : Benoit Claise [mailto:[email-masked]] 
Envoyé : mardi 3 mai 2005 17:33
À : STEPHAN Emile RD-CORE-LAN
Cc : [email-masked]
Objet : Re: [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt

Dear Emile,

Dear Benoit,

What is the max length of a fixed length field ? Is it 65534 ? 

The draft says: 

Field Length  
           The length of the corresponding encoded Information Element,  
           in octets.  Refer to [IPFIX-INFO].  The field length may be  
           smaller than the definition in [IPFIX-INFO] if reduced size  
           encoding is used (see section 6.2).  The value 65535 is    
           reserved for variable length Information Element (see  
           section 7). The Field Length MAY NOT 0. 
 
So we don't specify what the maximum length is, we simply say that 65535 is reserved. Obviously this is below 65535. 
Anyway, the length is specify by the information model 

	Does that make sense as the max length of an IPFIX msg is 65535 ?

IMHO, this offers the maximum of flexibility.

At large, in the future IPFIX will need to define new kind of field types. The current definition of  'Field Length' must be prepared for that. I propose to reserve the MSB of 'Field Length' for future usage.

How to export in UDP an IPFIX Message whose length is above 65535 is not that such a trivial issue!
So I propose to start with IPFIX 1.0, get some adoption, see the limitations, and go from there.

Regards, Benoit.

Regards

Emile

________________________________

De : majordomo listserver [mailto:[email-masked]] De la part de Benoit Claise
Envoyé : mardi 19 avril 2005 01:43
À : [email-masked]; me
Cc : Paul Aitken
Objet : [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt

Dear all, 

I just posted a new version of the IPFIX protocol draft, with the feedback from Paul Aitken's thorough review.

Here are the list of changes:
- Some cross references were wrong
- Flow Record definition exactly similar to the one in [IPFIX-ARCH]
- Template definition exactly similar to the one in [IPFIX-ARCH]
- As deduced from section 9, the source ID definition now contains: the source ID MUST NOT be 0
- The Field Length is completed with: The value 65535 is reserved for variable length Information Element (see section 7). The Field Length MAY NOT 0. 
- one mistake corrected in figure O
- correction: In most cases the length of the Information Element will be less than 256 255 octets.
- correction: The IPFIX Message Header 16-bit Length field limits the length of a IPFIX Message to 65536 65535 octets including the header.
- section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) BTW, the TCP sections now speaks of TCP connection as opposed to TCP association
- added the 2 sentences

   When the TCP connection restarts, the Exporting Process MUST resend 
   all the Template Records.  
     
   When an TCP connection is closed, the Collecting Process MUST 
   discard all templates received over that connection and stop 
   decoding IPFIX Messages that use those templates. 
- A couple of mistakes in the examples.
 
I advice to review the changes at http://ietf.levkowetz.com/drafts/ipfix/, once the draft is published. 
 
Regards, Benoit.

 

- A lot of editorial corrections and improvements

---

From: Benoit Claise <[email-masked]>
Date: Thu, 12 May 2005 12:49:56 +0200

Dear Emile,

> Dear Benoit,
>
>  
>
> Currently downcasting is a property of the protocol. To give 
> flexibility to new Information Elements definition it must be an 
> Information Element property. In the following example foo definition 
> says that it can be downcasted as B and C. That is not feasible 
> currently because downcasting is hardcoded in the protocol.
>
>  
>
> Name:                          foo
>
> Description:                 ""
>
> Abstract Data Type:      A
>
> ElementId:                    555
>
> Dowcasting:                 B and C
>
>  
>
> There is another benefit to define downcasting in the info model: It 
> will be possible to limit downcasting to a subset of integer (e.g. 
> unsigned64 to unsigned32 only instead of unsigned64 to unsigned32 or 
> to unsigned16 or to octet).
>
I think this is the wrong approach: downcasting should be part of the 
protocol. The IPFIX device, based on what he knows, should decide 
whether downcasting is the appropriate choice. It should also decide to 
which type to downcast. For example: the IPFIX device is the only one to 
know, based on its architecture,  to which type it could downcast an 
ingressInterface.

Regards, Benoit.

>  
>
>  
>
> Regards
>
> Emile
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> *De :* Benoit Claise [mailto:[email-masked]]
> *Envoyé :* mercredi 4 mai 2005 16:32
> *À :* STEPHAN Emile RD-CORE-LAN
> *Cc :* [email-masked]; Juergen Quittek
> *Objet :* Re: info model flexibility
>
>  
>
> Hi Emile,
>
> Hi Benoit,
>
>  
>
> The info model (section 2.1) is designed to be managed dynamically by 
> IANA without moving to a new protocol version. So I consider that more 
> flexibility must be given to the specification of Information Elements 
> in the info model. Let's take a real example:
>
> Downcasting is currently defined in the protocol specification. 
> Consequently it will not be possible to use them in the future with 
> new field types.
>
> I don't understand why?
>
>  
>
>
>
> The agreement was that the I.E. must define its maximum length. This 
> was required by the database guys who wanted to be able to define 
> their schemas.
> If an exporter doesn't have to use the full length, why export it? 
> This is a protocol issue and not an information model issue.
>
>  
>
> What about replacing "dataType - One of the types listed in section 
> 3.1 of this document..." with" dataType - Types listed in section 3.1 
> of this document..." ?
>
> ------------------------------------------------------------------------
>
> *De :* Benoit Claise [mailto:[email-masked]]
> *Envoyé :* mardi 3 mai 2005 17:33
> *À :* STEPHAN Emile RD-CORE-LAN
> *Cc :* [email-masked] <mailto:[email-masked]>
> *Objet :* Re: [ipfix-protocol] new version of the IPFIX protocol 
> draft: draft-ietf-ipfix-protocol-12.txt
>
>  
>
> Dear Emile,
>
> Dear Benoit,
>
>  
>
> At large, in the future IPFIX will need to define new kind of field 
> types. The current definition of  'Field Length' must be prepared for 
> that. I propose to reserve the MSB of 'Field Length' for future usage.
>
> ------------------------------------------------------------------------
>
> *De :* majordomo listserver [mailto:[email-masked]] *De 
> la part de* Benoit Claise
> *Envoyé :* mardi 19 avril 2005 01:43
> *À :* [email-masked] 
> <mailto:[email-masked]>; me
> *Cc :* Paul Aitken
> *Objet :* [ipfix-protocol] new version of the IPFIX protocol draft: 
> draft-ietf-ipfix-protocol-12.txt
>
>  
>
> Dear all,
>
> I just posted a new version of the IPFIX protocol draft, with the 
> feedback from Paul Aitken's thorough review.
>
> - The Field Length is completed with:** **The value 65535 is reserved 
> for variable length Information Element (see section 7). The Field 
> Length MAY NOT 0.
> - correction: In most cases the length of the Information Element will 
> be less than 256 **255** octets.
> - correction: The IPFIX Message Header 16-bit Length field limits the 
> length of a IPFIX Message to 65536 **65535** octets including the header.
> - section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops 
> ;) BTW, the TCP sections now speaks of TCP connection as opposed to 
> TCP association
> - added the 2 sentences
>
>** **