Subject: [ipfix-reqs] Flow definition

From: Ganesh Sadasivan <[email-masked]>
Date: Fri, 20 Jun 2003 13:34:59 -0700

I was comapring the terminology used in requirements against
architecture. The req spec defines flows as:

"A flow is defined as a set of IP packets passing an observation point
in the network during a certain time interval."

The arch. spec just mentions it as "packets" and not "IP packets".

The "IP packets" does not sound really correct if we are talking about
defining flows based on MPLS too. An MPLS packet could encapsulate
a non-IP packet and if one defines a flow based on just labels, then
it beats the above definition.

I have the following proposal:
1.
"A flow is defined as a set of IP packets or a sub-IP encapsulated IP
packets passing
an observation point in the network during a certain time interval."
2.
In the section on MPLS there should be  a statement telling that for
MPLS packets,
the  metering process has to dig into the packet or by some other means
find out if the encapsulated packet is an IP packet.

Any other suggestions?

Thanks
Ganesh

--
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: "Carter Bullard" <[email-masked]>
Date: Thu, 26 Jun 2003 15:37:07 -0400

Gentle people,
   I agree with Simon and want to add that encapsulations
are not the only extension issue, as there are metrics
that we vendors will want to transport that are not in
any of the drafts.  Just as long as we have a decent
vendor extension strategy then there will not be any
problem.

Carter

> -----Original Message-----
> From: majordomo listserver 
> [mailto:[email-masked]] On Behalf Of Simon Leinen
> Sent: Thursday, June 26, 2003 3:31 PM
> To: Nevil Brownlee
> Cc: Simon Leinen; Ganesh Sadasivan; Harrington,David; 
> [email-masked]
> Subject: [ipfix] Re: [ipfix-reqs] Flow definition
> 
> 
> Nevil Brownlee writes:
> > Hi Simon:
> 
> >> Ganesh Sadasivan writes:
> >> > Thanks David. I re-read the charter & agree that the charter does
> >> > not mention about MPLS flows. But the question is if 
> flow collection
> >> > is done on MPLS encapsulated IP packet ? If so should we not
> >> > explicitly include them in the flow definition.
> >> 
> >> I would say no, we shouldn't.
> 
> > I've been working with Ganesh on editing the Architecture Draft.
> > Seems to me that this is an issue which needs more discussion.
> > Here's my thoughts on it:
> 
> >  - If a network element (switch or router) understands things like
> >    MPLS, it makes sense to let it use that understanding in creating
> >    flows.
> 
> Maybe, but MPLS is just one of many possible encapsulations for IP
> packets.  I don't think MPLS-specific attributes should be treated any
> differently from e.g. attributes that are specific to ATM, Ethernet,
> Frame Relay, POS.  This would be a somewhat open-ended endeavour, so
> I'd like to keep this out of the base IPFIX standards.
> 
> Just defined MPLS-specific IPFIX attributes in a specific-lower-layer
> extension to IPFIX.  There can be other extensions for Ethernet etc.
> 
> >  - On the other hand, we have to define a 'base specification,'
> >    i.e. what's the minimum set of packet attributes an IPFIX
> >    exporter MUST support if it claims to be IPFIX-conformant?
> 
> >  - It's very difficult to decide where to draw the line on this.
> >    MPLS is clear enough, but how about other encapsulations,
> >    e.g. IP-in-IP, GRE, etc.?  Application information, e.g. in
> >    RTP header fields [RFC1889], raises even more questions.
> 
> > How about the following as a minimal definition for the header
> > fields which can define a flow?  (This is one of three list items in
> > the current Architecture Draft).
> 
> > * One or more header fields of the actual packet, e.g. destination
> >    IP address, or one of the fields in the packet's encapsulation
> >    header, e.g. label for MPLS, tunnel end-points for IP-in-IP, etc.
> 
> > The IPFIX Information Model could specify encapsulation-header-based
> > attributes as they seem neccessary and/or useful ...
> 
> Yes, but I suggest to keep specific lower layers out of the base
> document set.
> -- 
> Simon.
> 
> --