Subject: RE: [ipfix] IPFIX Requirement presentation

From: "Norseth, KC" <[email-masked]>
Date: Tue, 8 Jan 2002 16:05:21 -0500

You got it!

|-----Original Message-----
|From: Ganesh Sadasivan [mailto:[email-masked]] 
|Sent: Tuesday, January 08, 2002 1:48 PM
|To: K.C. Norseth
|Cc: Simon Leinen; [email-masked]
|Subject: Re: [ipfix] IPFIX Requirement presentation
|
|
|What appears to be more appropriate to me here is to associate 
|flows with an observation point rather than with an interface. 
|The observation point could be one of a full system, a set of 
|interfaces, a logical interface or even
|
|a sub-interface depending on how granular the measuring device 
|can get upto. Ganesh
|
|"K.C. Norseth" wrote:
|
|> In the case of an etxternal probe where there is only one interface 
|> and the probe is hooked to a mirrored port or bridge, the 
|place where 
|> the probe is connected, ther is no incomoing or outgoing interface. 
|> What would the interface be that would satisfy MUST?
|>
|> K.C.
|>
|> ----- Original Message -----
|> From: Simon Leinen <[email-masked]>
|> To: Ganesh Sadasivan <[email-masked]>
|> Cc: <[email-masked]>
|> Sent: Sunday, January 06, 2002 5:56 AM
|> Subject: Re: [ipfix] IPFIX Requirement presentation
|>
|> > >>>>> "gs" == Ganesh Sadasivan <[email-masked]> writes:
|> > >    I want to bring up this point which I had raised on the
|> > >    requirement spec. at the WG meeting.
|> > >    It is from slide 5 on requirements where the flow 
|definition has
|> > >    been changed to include "incoming or outgoing interface" as a
|> > >    MUST.
|> >
|> > The corresponding part of the requirements draft
|> > (ietf-ipfix-requirements-00) reads:
|> >
|> >   3.1. Interfaces
|> >
|> >      The measuring device MUST be able to separate flows 
|by the incoming
|> >      interface or by the outgoing interface or by both of them.
|> >
|> > Note that this says "MUST be able to separate", not "MUST 
|separate". 
|> > Therefore I think your reasoning below doesn't apply:
|> >
|> > >    There are cases like a SP is interested in getting all the
|> > >    packest that go between 2 ASs. This does not have any strict
|> > >    relevance to interface. An AS can be sourced by Multiple
|> > >    interfaces in a router. Similar would be case if somebody
|> > >    considers to define a flow based on other packet fields like
|> > >    src/dst IP etc. In the general scheme of flow 
|defintion ,I do not
|> > >    see why there should be a restriction to include the 
|interfaces
|> > >    as a MUST. Claiming this as "most of the apps need 
|the interfaces
|> > >    today" is not a valid argument as this model is used 
|to serve for
|> > >    future apps. too.  Therefore I request the WG to consider
|> > >    removing this restriction.
|> >
|> > It is probably the case for *every* flow attribute that one can 
|> > always come up with a sensible application that doesn't care about 
|> > it.  So it makes looks reasonable to make all flow attributes 
|> > optional, in the sense that when an application isn't 
|interested in 
|> > them, the exporter doesn't have to send them in order to 
|avoid waste 
|> > of resources.  This could be a requirement for the Flow 
|Information 
|> > Export protocol.
|> >
|> > But it also makes sense to make the *ability* of reporting certain 
|> > attributes mandatory, so that applications can rely on them being 
|> > available from all IPFIX compliant exporters.
|> >
|> > Personally I find the input and output interface sufficiently 
|> > important to make their support mandatory.  In particular 
|the input 
|> > interface is essential when one wants to do analysis of 
|large-scale 
|> > routing asymmetries.  Input and output interfaces are also 
|extremely 
|> > useful when one collects flows at different points in the networks 
|> > and wants to avoid counting the same flows twice.  And the input 
|> > interface cannot be derived from the source address and routing 
|> > information, as can/must be done with e.g. the "source netmask", 
|> > "upstream AS" or "source AS".
|> >
|> > Regards,
|> > --
|> > Simon Leinen        [email-masked]
|> > SWITCH    http://www.switch.ch/misc/leinen/
|> >
|> >        Computers hate being anthropomorphized.
|> >
|> > --
|> > 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/
|> >
|
|
|--
|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/
|