Re: [IPFIX] rfc5103 lite

Hi Brian,

On 03/06/2012 12:21 PM, Brian Trammell wrote:
> Hi, Andrew,
>
> I'm okay making it clear that 4.10 describes IEs you shouldn't imitate when desiging new IEs, not IEs you shouldn't use. It seems little weird to me to stick a specific exception for a non-IETF protocol (3954 is Informational) in a document about extending an IETF protocol.
Understood.  This is why I didn't flag this when I initially reviewed 
the ie-doctors draft.
>
> In the previous paragraph (new sentence on 3rd and 4th lines):
>
>          However, for reasons of history, there
>          are several Information Elements within the IANA registry which do not
>          follow best practices in Information Element design. These Information
>          Elements are not necessarily so flawed so as to require deprecation,
>          but they should be explicitly ignored when looking for guidance as to
>          whether a new Information Element should be added.
>
> I think the paragraph you cite, though, is pretty clear that these IEs are being called out because they duplicate existing IEs.
>
> That said... I'm a little confused as to how initiator/responderOctets/Packets allow 5103-lite in a V9-compatible way: they're allocated in IPFIX number space, not in v9 space.
In short these IEs don't require a PEN.

>   Can NetFlow V9 export such IEs? Are these exporters really using IPFIX without any IPFIX features (i.e., V9 with IPFIX message headers)? Or is it V9-heavy (V9 with new IPFIX IEs)?
Using your terminology I guess I would call what I am seeing "V9-heavy + 
vendor extensions".

I am seeing many NetFlow v9 exporters that

* send IEs above 127 (As long as they keep the the IPFIX datatype and 
semantics this is not a problem)
* implement vendor specific IEs without a PEN.  (I know of hundreds of 
vendor IEs above 32,767 defined by at least 5 vendors)

These same exporters are starting to implement biflows.  As much as I 
would prefer to see 5103, if v9 is being used I would prefer not to 
discourage the use of existing IEs.  Especially since the next step 
would be to define vendor specific reverse IEs.

However, you may be right that the current text is clear enough and 
ie-doctors isn't the place for a clarification.

-Andrew

>
> As for semantics, yep. We need to do a complete semantics review as part of the 5102-bis effort. Thanks for pointing out yet another place where these are inconsistent, though; we have our work cut out for us. :)
>
> Thanks, and cheers,
>
> Brian
>
> On Mar 6, 2012, at 5:54 PM, Andrew Feren wrote:
>
>> While reviewing the ie-doctors draft part of "4.10.  Avoiding Bad Ideas in Information Element Design" caught my attention.
>>
>> "Specific examples of
>>     such Information Elements include initiatorOctets and responderOctets
>>     (which duplicate octetDeltaCount and its reverse per [RFC5103]) and
>>     initiatorPackets and responderPackets (the same, for
>>     packetDeltaCount)."
>>
>> I agree that the initiatorOctets and initiatorPackets are redundant.  I also agree that in the context of IPFIX that responderOctets and responderPackets are made redundant by RFC 5103.  However, I think there is a valid use for the responderOctets and responderPackets IEs.
>>
>> I see a lot of interest in implementing biflows, but many exporters are still exporting NetFlow v9 (RFC 3954).  The IEs for responderOctets and responderPackets allow a limited version of 5103     to be exported until the exporter can support IPFIX.  I'm not sure we want to paint these two IEs with the "bad idea" brush.  Maybe we could add a couple sentences to clarify the situation.
>>
>> Something along the lines of
>> For 3954 use of responderOctets and responderPackets is OK, but don't expect new responder/reverse IEs to be added.  If you need more reverse IEs then IPFIX and 5103 should be implemented.
>>
>> We should also fix initiatorPackets and responderPackets to not have "identifier" semantics.
>>
>> -Andrew
>> _______________________________________________
>> IPFIX mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix