Subject: Re: [ipfix] [issue] INFO-27 Information model reconciliation with NetflowV9 Draft

From: "Jeff Meyer" <[email-masked]>
Date: Thu, 29 Jan 2004 10:02:24 -0800

Juergen,

  Yes, this was the problem I was trying to state.  In the Excel spreadsheet 
I've made some stab at what we may want to borrow.  I know long ago Paul 
Calato was planning to do some of this, but I don't think that happened.

  I'd be interested in hearing other proposals for things to borrow from 
NFv9 from others on the mailing list.

  I also question whether the four items which are in IPFIX but not NFv9 are 
appropriate:

  - nextHopAS  - NFv9 talks about IP addrs of next hop, but not AS numbers, 
are both useful?
  - ipV4SourceExporterAddress - seems useful, is there a reason NFv9 didn't 
declare it?
  - ipV6SourceExporterAddress - seems useful, is there a reason NFv9 didn't 
declare it?
  - droppedPacketCount - seems useful, is there a reason NFv9 didn't declare 
it?

-- Jeff

>From: Juergen Quittek <[email-masked]>
>To: Jeff Meyer <[email-masked]>, [email-masked]
>Subject: Re: [ipfix] [issue] INFO-27  Information model reconciliation with 
>NetflowV9 Draft
>Date: Thu, 29 Jan 2004 12:57:57 +0100
>
>Jeff,
>
>The open problem I see here is fixing
>the set of information elements
>that are part of the IPFIX INFO model.
>We are free to choose this set except that
>we should avoid conficting numbers between
>NFv9 and IPFIX.
>
>Regards,
>
>    Juergen
>
>--On 26.01.2004 23:51 Uhr -0800 Jeff Meyer wrote:
>
>>There are a large number of information elements defined in the NFv9 draft 
>>in
>>section 8 "Field Type Definitions" which are not currently part of the 
>>IPFIX information
>>model.
>>
>>There are a smaller set of information elements currently defined in 
>>ipfix-info which
>>are not defined in NFv9.
>>
>>Note all common IE's are defined to have the same fieldId value.
>>
>>A summary of the deltas between the two documents is available at:
>>
>>   http://inetpix.com/ipfix/NFv9_IPFIX_info_comparison.xls
>>
>>It would appear that some of the information elements defined in NFv9 are 
>>actually
>>option data vs. flow data (see issue INFO-26 at 
>>http://ipfix.doit.wisc.edu/archive/2360.html).
>>
>>Proposal would be to take a subset of these information elements from NFv9 
>>into ipfix.
>>
>>The value of the current ipfix-info elements which fall outside of NFv9 is 
>>also worth
>>questioning.
>>
>>-- Jeff Meyer
>>
>>_________________________________________________________________
>>Let the new MSN Premium Internet Software make the most of your high-speed 
>>experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
>>
>>
>>--
>>Help        mailto:[email-masked] and say "help" in message 
>>body
>>Unsubscribe mailto:[email-masked] and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
>

_________________________________________________________________
Let the new MSN Premium Internet Software make the most of your high-speed 
experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Jan 2004 23:12:51 +0000

Jeff Meyer wrote:

> Juergen,
> 
>  Yes, this was the problem I was trying to state.  In the Excel 
> spreadsheet I've made some stab at what we may want to borrow.  I know 
> long ago Paul Calato was planning to do some of this, but I don't think 
> that happened.

I am working on reconsiling IPFIX and NFv9 and should have something
shortly.

> NFv9 from others on the mailing list.

Working on it.

>  I also question whether the four items which are in IPFIX but not NFv9 
> are appropriate:
> 
>  - nextHopAS  - NFv9 talks about IP addrs of next hop, but not AS 
> numbers, are both useful?

You need to know the AS for peering charges, saves the collector having
to figure it out by merging BGP next hop and the output from IBGP.

>  - ipV4SourceExporterAddress - seems useful, is there a reason NFv9 
> didn't declare it?

NFv9 did not really consider proxies which I think need this.

>  - ipV6SourceExporterAddress - seems useful, is there a reason NFv9 
> didn't declare it?

As above

>  - droppedPacketCount - seems useful, is there a reason NFv9 didn't 
> declare it?

I don't think that this is available to Netflow. For example if RED dropped
the packet, it does not have the ability to call back into Netflow to report it.
Same for any multi-linecard drop.

It is simple to declare it, but I would not expect that it would be
found on many of the high end platforms due to implementation constraints.

- Stewart

>> Subject: Re: [ipfix] [issue] INFO-27  Information model reconciliation 
>> with NetflowV9 Draft
>>> There are a large number of information elements defined in the NFv9 
>>> draft in
>>> section 8 "Field Type Definitions" which are not currently part of 
>>> the IPFIX information
>>> model.
>>>
>>> It would appear that some of the information elements defined in NFv9 
>>> are actually
>>> Proposal would be to take a subset of these information elements from 
>>> NFv9 into ipfix.
>>>
>>> The value of the current ipfix-info elements which fall outside of 
>>> NFv9 is also worth
>>> questioning.
>>>
>>> -- Jeff Meyer
>>>
>>> Let the new MSN Premium Internet Software make the most of your 
>>> high-speed experience. 
>>> http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
>>>
>>>
>>> -- 
> Let the new MSN Premium Internet Software make the most of your 
> high-speed experience. 
> http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
> 
> 
> --