Subject: [IPFIX] Mistake in PSAMP RFCs: Selector ID length

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Oct 2009 10:45:20 +0200

Dear all,

We found a mistake in the PSAMP RFCs.

RFC5477

            8.1.2. selectorId

       Description:

          The Selector ID is the unique ID identifying a Primitive Selector.
          Each Primitive Selector must have a unique ID in the Observation
          Domain.

       Abstract Data Type:  unsigned16                  <------------------

       Data Type Semantics:  identifier

       ElementId:  302

       Status:  current

RFC5476, the selectorID length is 4 bytes in ALL examples (and there are 
many).

   IPFIX Options Template Record:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Set ID = 3           |          Length = 26          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Template ID = 262      |         Field Count = 4       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Scope Field Count =  1    |0|  selectionSequenceId = 301  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Scope 1 Length = 4      |0|     ingressInterface = 10   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Field Length = 4       |0|      selectorId = 302       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Field Length = 4       |0|      selectorId = 302       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Field Length = 4       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The proposed solution is to increase the Selector ID length and put an 
ERRATA on RFC5477.
16 bits is definitely not enough and clearly not was intended. Since we 
can do reduced length encoding with larger identifiers, we don't see any 
harm in making all identifiers 64 bit

Feedback?

Regards, Benoit.

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 15 Oct 2009 11:27:16 +0200

Benoit,

>    IPFIX Options Template Record:

4 Bytes = 32 Bit

You propose to increase it to 64 (=8 Byte), which means that both RFCs 
need to be corrected. Or is 64 a mistake?

Regards,
Gerhard

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

-- 
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:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Oct 2009 11:34:59 +0200

Gerhard,
>> RFC5476, the selectorID length is 4 bytes in ALL examples (and there 
>> are many).
>>
>> The proposed solution is to increase the Selector ID length and put 
>> an ERRATA on RFC5477.
>> 16 bits is definitely not enough and clearly not was intended. Since 
>> we can do reduced length encoding with larger identifiers, we don't 
>> see any harm in making all identifiers 64 bit
>>
>> Feedback?
>
> 4 Bytes = 32 Bit
>
> need to be corrected. 
Not really since the examples can use reduced length encoding.
Since we have to change it (at least this is the proposed solution), why 
not going directly to 64 bits?

Regards, Benoit.
> Or is 64 a mistake?

---

From: Brian Trammell <[email-masked]>
Date: Thu, 15 Oct 2009 11:41:05 +0200

hi Benoit, Gerhard,

I agree with the change to 64 bit, to keep it in line with every other  
protocol-level identifier (save odID, bound by the header format to 32  
bits), with the understanding that RLE will often be used to use it as  
32 bit.

However, in this case we might want as well to update 5476 with a line  
noting that all the examples use RLE.

Best regards,

Brian

On Oct 15, 2009, at 11:27 AM, Gerhard Muenz wrote:

>>      RFC5476, the selectorID length is 4 bytes in ALL examples (and  
>> there are many).
>> 16 bits is definitely not enough and clearly not was intended.  
>> Since we can do reduced length encoding with larger identifiers, we  
>> don't see any harm in making all identifiers 64 bit
>> Feedback?
>
> 4 Bytes = 32 Bit
>
> You propose to increase it to 64 (=8 Byte), which means that both  
> RFCs need to be corrected. Or is 64 a mistake?
>
> Regards,
> Gerhard
>
>> Regards, Benoit.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 15 Oct 2009 13:44:32 +0200

It looks like two errata on RFC 5478 and 5477 should be issues. I suggest that one of you takes the pen to enter the errata texts, and when they are ready and have reached consensus I can approve them. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Trammell
> Sent: Thursday, October 15, 2009 11:41 AM
> To: Gerhard Muenz
> Cc: psamp; [email-masked]
> Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length
> 
> hi Benoit, Gerhard,
> 
> I agree with the change to 64 bit, to keep it in line with 
> every other protocol-level identifier (save odID, bound by 
> the header format to 32 bits), with the understanding that 
> RLE will often be used to use it as
> 32 bit.
> 
> However, in this case we might want as well to update 5476 
> with a line noting that all the examples use RLE.
> 
> Best regards,
> 
> Brian
> 
> >>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed solution is to 
> >> increase the Selector ID length and put an ERRATA on RFC5477.
> >> don't see any harm in making all identifiers 64 bit Feedback?
> >
> > 4 Bytes = 32 Bit
> >
> ---------------------------------------------------------------------
> >> --- _______________________________________________
> >> IPFIX mailing list
> >> [email-masked]
> > Chair for Network Architectures and Services (I8) Technische 
> > Universität München - Department of Informatics 
> Boltzmannstr. 3, 85748