Subject: [ipfix-req] egress multicast interfaces: risk of inconsistancy

From: "STEPHAN Emile FTRD/DAC/LAN" <[email-masked]>
Date: Fri, 26 Jul 2002 17:38:08 +0200

Hi all,

Sorry to butt in so late in the discussion.

in the draft draft-stephan-ippm-multicast-metrics-00.txt I define a
metric named Type-P-Multicast-Instantaneous-Connectivity as "Given a
Type P packet sent by the multicast source Src at T0 and Node a router
acting as a multicast repeater, a Type-P-Multicast-
Instantaneous-Node-Connectivity is defined as the number of time the
packet P is repeated by this node."

The value of the metric corresponds exactly to instantaneous egress
multicast interface number of a packet of a multicast flow.

As the number of listeners changes during the metering task there is a
risk of inconsistency of the value of the egress multicast interfaces
number ( or of the list of the egress multicast interfaces) exported.

Perhaps a new flow ticket may be started when the number of egress
interfaces or the list of the egress interfaces change ?

hope that help to determine the requirements constraints. 

regards
Emile

> -----Message d'origine-----
> De : Carter Bullard [mailto:[email-masked]]
> Envoye : vendredi 26 juillet 2002 16:00
> A : 'Benoit Claise'; [email-masked]
> Objet : RE: [ipfix-req] Section regarding multicast flows
> 
> 
> 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/
> 

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