Subject: [IPFIX] rfc5103 lite

From: Andrew Feren <[email-masked]>
Date: Tue, 06 Mar 2012 11:54:21 -0500

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

---

From: Brian Trammell <[email-masked]>
Date: Tue, 6 Mar 2012 18:21:40 +0100

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.

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. 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)?

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
> 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.
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Tue, 06 Mar 2012 17:32:44 +0000

Brian,

> 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. Can NetFlow V9 export such IEs?

Yes, of course.

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

There's nothing heavy about it: equivalent definitions have been ported 
from the IPFIX infomodel to the NFv9 infomodel.

P.

---

From: Andrew Feren <[email-masked]>
Date: Tue, 06 Mar 2012 13:29:28 -0500

Hi Brian,

> 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 pro…
Understood.  This is why I didn't flag this when I initially reviewed 
the ie-doctors draft.
> 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

---

From: Paul Aitken <[email-masked]>
Date: Tue, 06 Mar 2012 21:50:42 +0000

Andrew,

> * send IEs above 127

Of course. It's a 16-bit number space.

> (As long as they keep the the IPFIX datatype and semantics this is not 
> a problem)

Note that NFv9 and IPFIX are two different protocols, so there's no 
requirement for the IPFIX datatype and semantics to apply to the same 
field ID in NFv9.

- although in our case, we've endeavoured to do this as much as 
possible, assuming virtual equality between the two infomodels.

> vendor IEs above 32,767 defined by at least 5 vendors)

NFv9 doesn't have any vendor-specific IEs. It's a cisco protocol, and we 
might define any field to have any meaning at any time.

Also, there's no requirement for non-cisco vendors to use IDs > 32768. 
They could use any ID in the NFv9 range.

After discussing with Mike, I recently allocated some blocks of IDs 
within the NFv9 range for different vendors, in an effort to prevent us 
re-defining the same fields for different purposes.
It's only a pity that the vendors didn't approach me first.

Vendors, reach out to me if you're exporting your own NFv9 fields so we 
can avoid ID collisions.

P.

---

From: Andrew Feren <[email-masked]>
Date: Thu, 08 Mar 2012 09:13:44 -0500

> Of course. It's a 16-bit number space.
Agreed.  I was mostly responding to Brian's "not in v9 space" comment.  
I assumed he was referring to "Information Element identifier values in 
the sub-range of  1-127 are compatible with field types used by NetFlow 
version 9" from RFC 5102.

>> (As long as they keep the the IPFIX datatype and semantics this is 
>> not a problem)
>
Understood.
> possible, assuming virtual equality between the two infomodels.
And I appreciate that effort.  Since NFv9 is Cisco's protocol I tend to 
treat what Cisco does for v9 as "standard", but point taken that there 
is no actual requirement.

>> * implement vendor specific IEs without a PEN.  (I know of hundreds 
>> of vendor IEs above 32,767 defined by at least 5 vendors)
>
> NFv9 doesn't have any vendor-specific IEs. It's a cisco protocol, and 
> we might define any field to have any meaning at any time.

OK, but I wasn't sure what else to call an IE that isn't in any 
standard, is sent only from one vendor, and is sent using a protocol 
that looks suspiciously like NetFlow v9.  :-)

> They could use any ID in the NFv9 range.

Agreed.  My bias toward keeping v9 IEs that are not also standard IPFIX 
in a range that won't conflict with an eventual IPFIX IE leaked through.

> within the NFv9 range for different vendors, in an effort to prevent 
> us re-defining the same fields for different purposes.
> Vendors, reach out to me if you're exporting your own NFv9 fields so 
> we can avoid ID collisions.

Thanks for taking that on.

-Andrew