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

From: Paul Aitken <[email-masked]>
Date: Thu, 25 Feb 2010 23:39:53 +0000

Dan,

As you will have seen, I just opened errata 2052 - 2059 for this.

Thanks,
P.

> 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
>>
>> On Oct 15, 2009, at 11:27 AM, Gerhard Muenz wrote:
>>
>>> Benoit,
>>>
>>> Benoit Claise wrote:
>>>> 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?
>>> 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
>>>
>>> _______________________________________________
>>> IPFIX mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipfix
>>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

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

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 26 Feb 2010 11:02:32 +0100

Dear all,

IMO, the distinction between "protocol-level" and other identifiers is 
quite arbitrary.

Most identifiers are currently unsigned32:
http://www.iana.org/assignments/ipfix/ipfix.xhtml

If we change selectorId to unsigned32, it would be consistent other 
identifiers and with IPFIX-MIB, where we have:
ipfixSelectionProcessSelectorIndex    Unsigned32

However, if you want to change it to unsigned64, why shouldn't we change 
observationPointId etc. as well?
And what about ipfixSelectionProcessSelectorIndex?
The IPFIX-MIB does not say that
ipfixSelectionProcessSelectorIndex == selectorId,
yet this would be an obvious implementation.

These are just some thoughts about possible consequences, which does not 
mean that I do not like unsigned64 in general.

Regards,
Gerhard

-- 
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