Subject: [ipfix-req] multicast replication factor

From: Juergen Quittek <[email-masked]>
Date: Tue, 16 Jul 2002 02:55:26 +0200

Dave,

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?

(Currently, we have MUST and MAY requirements for attributes.
This would be the first attribute with a SHOULD.)

    Juergen

--
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: Benoit Claise <[email-masked]>
Date: Tue, 16 Jul 2002 11:00:08 +0200

Juergen,

> This would be the first attribute with a SHOULD.) 

It could be a SHOULD.
But actually, I would like to stress that only one of the two following 
solutions will make sense, depending on what you want to do with the data.
A multicast flow can be represented as:
1. a set of unicast flows with the corresponding egress ifIndex (where 
it's possible to get the egress Ifindex. Remember Peram's argument 
during the WG meeting)
OR
2. one flow with no egress  ifIndex but with the replicator factor 
(where it's possible to get the replicator. Remember Peram's argument 
during the WG meeting)

So maybe we could have a small paragraph specific for multicast like this:
SHOULD (unicast flow + SHOULD egress IfIndex) OR (Multicast flow + 
SHOULD replicator - egress ifIndex)

Regards, Benoit.

---

From: Dave Plonka <[email-masked]>
Date: Thu, 18 Jul 2002 06:11:43 -0500

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

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

---

From: Vamsidhar Valluri <[email-masked]>
Date: Thu, 18 Jul 2002 14:17:45 -0700 (PDT)

Dave,
 Please see inline

>    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

---

From: Dave Plonka <[email-masked]>
Date: Thu, 18 Jul 2002 20:45:47 -0500

> On Thu, 18 Jul 2002, Dave Plonka wrote:
<snip>
> lifetime. Correct me if i missed something.

Yes, I was assuming we all understood that.

If the egress interface ifIndex is configured to be one of the flow
attributes, then a change to the set of egress interfaces for a mcast
flow can simply cause flows to be expired and or created accordingly.

As for the load imposed, currently unicast DoS floods can cause tens of
thousands of flows per second to be reported, a few extra mcast flows
here and there (grouped at least by egress interface) is a trivial
amount.

Dave

---

From: Benoit Claise <[email-masked]>
Date: Tue, 23 Jul 2002 15:54:59 +0200

Dave,

>   intend to conform to IPFIX.
Agreed.

>   ingress and egress ifIndexes as keys", or something similar.
Agreed. I haven't spent a lot of time trying to get the perfect english 
sentences!
My only concern was if we had a flow record with one of the attributes 
having a variable number of instances, e.i. one flow record with several 
egress interfaces.

>the replication factor but not also determine the set of egress
Agreed.

Regards, Benoit.