Subject: RE: [ipfix-req] Section regarding multicast flows

From: "Carter Bullard" <[email-masked]>
Date: Fri, 26 Jul 2002 10:00:12 -0400

Hey Beniot,
In cases where there are valid exceptions to a
requirement candidate, a MUST generally converts to
a SHOULD or OPTIONAL.  One reason for this is 
you don't want to have to identify and manage
the complete list of possible exceptions during the
life of the RFC.  You already have exceptions for
certain types of IPFIX devices and specific types
of traffic that don't require egress interface
reporting.  That on its own might suggest that
egress interface reporting should be OPTIONAL
in the Data Model.  But if that is not compelling,
we may need to add more exceptions to the list than
are already there.

I can think of a few more types of traffic where
egress interface reporting may be challenging, such as
flow reporting under flap conditions, load balanced
traffic and port mirrored traffic.  In switches,
broadcast traffic generates the same problem set as
multicast traffic.  Also many switches, when presented
with some arp table issues, will broadcast unicast
datagrams to all interfaces. Should the multiple egress
interfaces be reported in this case?  That condition
would persist, ideally, for only a few packets.  Do
you generate multiple flow reports, one for the
broadcasted set of packets, and then one for the non
broadcasted flow?

One issue that comes up when considering multicast
egress interface reporting is that in most vendors
multicast implementations the multicast traffic is
delivered to every egress interface through hardware
broadcast, and then output filters decide whether to
forward the packet or not.  How does this generalize
in the IPFIX egress interface reporting strategy?
Does the IPFIX Data Model need to understand egress
interface filtering behavior for all traffic types
or just multicast?

It may be easier to just make egress interface
reporting an OPTIONAL feature, and then see if
any vendors can successfully implement it.

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 Benoit Claise
> Sent: Friday, July 26, 2002 4:21 AM
> To: [email-masked]
> Subject: [ipfix-req] Section regarding multicast flows
> 
> 
> 
> 
> Dave and All,
> 
> Trying to incorporate all the proposed changes discussed both 
> at the IETF meeting and on the mailing list in the new 
> requirement draft version, 
> I think that we should add a new section on multicast
> 
> 5.7 Multicast Flows
> 
> For a multicast packet replicated to multiple output 
> interfaces, the metering 
> process SHOULD maintain discrete flow records per different 
> egress ifIndexes. For example an incoming multicast packet 
> that is replicated to four output interfaces would be 
> reported in four different flow records that differ by the 
> output interface. In case the metering process doesn't 
> maintain and report discrete flow records 
> per different egress ifIndexes for a multicast flow, the 
> metering process 
> SHOULD export the multicast replication factor in the flow record.
> 
> 
> Furthermore, some extra changes are needed
> The requirement draft was saying:
> 
>     6.1.  Information Model
>     ...
>     The exporting process MUST be able to report the 
> following attributes
>     for each measured flow:
>     ...
>     8. output interface (ifIndex)
>     This requirement does not apply if the observation point is
>     located at a probe device. This requirement does not apply
>     in case of multicast flow records.
>     ...
>     The exporting process MAY be able to report the following 
> attributes
>     for each measured flow:
>     ...
>     25. multicast replication factor
>     the number of outgoing packets originating from a single
>     incoming multicast packet
> 
>     26. list of output interfaces for a multicast flow
> 
> 
> I would propose:
> 
>     6.1.  Information Model
>     ...
>     The exporting process MUST be able to report the 
> following attributes
>     for each measured flow:
>     ...
>     8. output interface (ifIndex)
>     This requirement does not apply if the observation point is
>     located at a probe device. _(ATTENTION: I REMOVED THE 
> LINE ABOUT MULTICAST)_
>     ...
>     The exporting process _SHOULD_ be able to report the 
> following attributes
>     for each measured flow:
>     ...
>     X. multicast replication factor
>     The number of outgoing packets originating from a single
>     incoming multicast packet. This _multicast_ replication 
> factor SHOULD be reported,
>     but only SHOULD if the list of output interfaces for this 
> multicast 
>     flow is not reported.
> 
>     _X+1. list of output interfaces for a multicast flow _(I 
> WOULD REMOVE IT
>     BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW SECTION 
> AND THE LIMITATION
>     IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED)
> 
> 
> What do you think?
> 
> Regards, Benoit
> 
> 
> 
> 
> --
> 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/

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 Jul 2002 14:13:38 +0200

Carter,

>traffic 
You have 2 good examples here.

>and port mirrored traffic.  In switches,
Well, for switches (layer 2 devices) I think that we shouldn't report 
any flow records.
Only the layer 3 devices should.

>any vendors can successfully implement it.
You've got a valid point.Why not a SHOULD?

       SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.

Any other opinion?

Regards, Benoit.

---

From: Nevil Brownlee <[email-masked]>
Date: Wed, 31 Jul 2002 09:22:16 +1200

> Only the layer 3 devices should.

Just a brief comment:

The days when devices could be strictly classified as "layer n" have
surely gone, as vendors make switches with layer 3 and often 4 features.
I don't think the WG should make any assumptions about what kind of
devices vendors implement IPFIX in - as long as they report flows using
the IPFIX standard, that's all that users will care about!

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x8941      ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
University of Auckland Webmail
http://webmail.auckland.ac.nz