Subject: RE: [ipfix-req] multicast replication factor

From: "Carter Bullard" <[email-masked]>
Date: Sat, 20 Jul 2002 12:20:23 -0400

Gentle people,
   The question of whether a flow monitor should or can
report the egress interfaces for multicast flows is really
answered only from the perspective of the flow definition.
Because IPFIX data does not have a rigid flow model, it 
may be premature to put restrictions on what multicast
flow modelers can or should do.

Multicast flows can be viewed as simple half-duplex streams,
which are generally not very useful, or they can be viewed
as complex session transactions, with member joins and leaves
acting as session signaling protocols, IPPM Type P1-P2 Flows.
In the first case, simple attributes such as the fully qualified
domain name (FQDN) of the sender address, or the observed end-to-end
path, or the egress interface list are interesting.  In the
second case, these attributes are not necessarily useful or
necessarily exist.

When secondary attributes such as the FQDN are applicable,
managing the reporting of these secondary attributes and how
they are associated with a flow can introduce a large
number of issues with regard to flow caching strategies that
may make them a serious attractive nusiance rather than
useful data.

Reporting the fanout interface list for a multicast half-duplex
stream is technically identical to reporting the FQDN for a
source address in a generic 5-tuple flow.  Adding the FQDN
to a flow record is interesting, but challenging, because the
information is not derivable from the packet stream itself.
This introduces flow caching issues that are very difficult
to deal with.

How do I get the FQDN to report in the flow?  Do I report the
FQDN in every flow record, or do I only report it when the
FQDN changes?  If I don't have a FQDN, can I report the flow?
Can I even tally the counters of the flow?  What is the
granularity of assurance of the FQDN to flow mapping?  If I
report that a packet was observed and I report it as being
associated with this FDQN, does the metric it have to be true?
Very expensive to ensure/assure that it's true. If it doesn't have
to be true, then what is its usefulness?  Can I bill on the
information?  Maybe, maybe not. Can I manage the network with
it?  No, because it isn't reliable.

These issues are more important for the multicast egress
interface list, which, by the way is a more difficult task
than the simple task of reporting the FQDN.

I would suggest that if you are building a multicast fanout
monitor, then these issues will be great technilogical problems
to solve.  If you're not, then including these features as
requirements to generic flow monitoring may negatively impact
the effort.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street
Suite 18K
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

> -----Original Message-----
> From: majordomo listserver 
> [mailto:[email-masked]] On Behalf Of Vamsidhar Valluri
> Sent: Thursday, July 18, 2002 5:18 PM
> To: Dave Plonka
> Cc: [email-masked]
> Subject: Re: [ipfix-req] multicast replication factor
> 
> 
> Dave,
>  Please see inline
> 
> On Thu, 18 Jul 2002, Dave Plonka wrote:
> 
> > On Tue, Jul 16, 2002 at 02:55:26AM +0200, Juergen Quittek wrote:
> > >
> > > I am not sure about one issue we discussed at the session 
> yesterday. 
> > > We agreed that the individual reporting of each ougoing multicast 
> > > flow will become a SHOULD requirement. But what was the 
> agreement on 
> > > the multicast replication factor? Currently it is a MAY 
> requirement 
> > > t be able to report it. Did we agree to make it also a SHOULD 
> > > requirement?
> >
> > In the WG meeting, the question to the audience was whether or not 
> > folks were in favor of modifying the requirements document to state 
> > that a conforming implementation SHOULD report the set of egress 
> > interfaces (ifIndexes) for observed multicast traffic.
> >
> > In general, I agree with Benoit's follow-up, except that:
> >
> > 1) Whether or not current hardware implementations happen 
> to be able to
> >    determine and report the set of egress ifIndexes for multicast
> >    traffic is not interesting (to me) with respect to whether we say
> >    MAY or SHOULD.  In my mind, its obvious that an implementation
> >    SHOULD report something so useful as the set egress interfaces.
> >    (We're already compromising significantly, to accomodate existing
> >    hardware limitations, by not saying MUST.)  We should, 
> at least, say
> >    SHOULD where we intend to influence future implementations which
> >    intend to conform to IPFIX.
> >
> > 2) Referring to one of the two multicast options as 
> reporting "unicast"
> >    flows (for multicast traffic) is confusing.  A flow with 
> a multicast
> >    address as its destination is not a "unicast" flow.  Instead we
> >    should write "SHOULD maintain discrete flow records with both the
> >    ingress and egress ifIndexes as keys", or something similar.
> 
> vamsi> During a lifetime of a multicast session egress interface count
> varies because some members might join or leave. If we key on 
> egress ifIndexes it might result in different flows of same 
> session during it's lifetime. Correct me if i missed something.
> 
> thanks
> -vamsi
> 
>  >
> > Lastly, I suggest that that the replication factor SHOULD 
> be reported, 
> > but only SHOULD if the egress interfaces are not.  (I'm 
> having trouble 
> > conceiving of an implementation though that can accurately 
> determine 
> > the replication factor but not also determine the set of egress
> > interfaces.)
> >
> > Dave
> >
> > --
> > [email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  
> > Madison, WI
> >
> > --
> > 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/
> 
> 

--
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/