Subject: [ipfix] [Fwd: Reportin in and out interfaces (was: RE: [ipfix-req] Sectionregarding multicast flows)]

From: [email-masked]
Date: Fri, 23 Aug 2002 15:57:24 -0400

Forgot to copy the list.

Subject: Re: Reportin in and out interfaces (was: RE: [ipfix-req] Sectionregarding multicast flows)
From: [email-masked]
To: Ganesh Sadasivan <[email-masked]>
Date: Fri, 23 Aug 2002 15:18:04 -0400

Ganesh Sadasivan wrote:
> 
> [email-masked] wrote:
> 
> > If I understand correctly, if the observation point
> > is the output interface then reporting the input interface
> > is optional. And the other way around.
> 
> Agreed.
> 
> > If I got the packet
> > by some other means, then neither of them are part of the
> > observation point and thus are optional.
> 
> Can give an example for the case of  "some other means"?
> Ganesh

	I did not have one in mind but was just following
	the text to its logical conclusion to show that,
	according to the text, both are optional.

> 
> >
> >
> > But this still seems a little odd. Here is the definition of
> > SHOUD from RFC 2119
> >
> > 3. 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.
> >
> > Reading that, it sound like input and output interfaces should
> > be SHOULD since it is not an absolute requirement.
> >
> > Paul
> >
> > Benoit Claise wrote:
> > >
> > > Juergen,
> > >
> > > > Hi all,
> > > >
> > > > I have a new suggestion which might solve our reporting problem
> > > > for input and output interfaces.
> > > >
> > > > What about keeping input interface and output interfaces in the
> > > > MUST list of attributes that the exporter is capable of reporting
> > > > but changing the restriction as follows?
> > > >
> > > >      7. input interface (ifIndex)
> > > >         This requirement does only apply to flows for which the
> > > >         input interface is included in the observation point.
> > >
> > > But, it will always be the case?
> > >
> > >     2.2.  Observation Point
> > >        The observation point is a location in the network where IP packets
> > >        can be observed. Examples are a line to which a probe is attached, a
> > >        shared medium, such as an Ethernet-based LAN, a single port of a
> > >        router, or a set of interfaces (physical or logical) of a router.
> > >
> > > If the observation point is an port (interface), yes the input interface
> > > is the observation point
> > > If the observation point is a set of ports (interfaces), yes the input
> > > interface is part of the observation point
> > > If the observation point is a line card, yes ...
> > > If the observation point is a router, yes...
> > >
> > > What do I miss?
> > >
> > > >
> > > >      8. output interface (ifIndex)
> > > >         This requirement does only apply to flows for which the
> > > >         output interface is included in the observation point.
> > >
> > > How are you solving that way the following issue?
> > >  - multicast
> > >  - load balancing issue
> > >  - flap conditions
> > >
> > > You are only solving the issue of:
> > >   - the output interface belongs to another line card, and we don't know
> > > (yet) what it is
> > >   - the output interface is mirrored port (and it doesn't make sense to
> > > report it)
> > >
> > > Regards, Benoit.
> > >
> > > >
> > > >
> > > >
> > > >    Juergen
> > > >
> > > >
> > > > --On 19 August 2002 18:51 +0200 Juergen Quittek <[email-masked]>
> > > > wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> The discussion on reporting output/egress interfaces now has
> > > >> extended to reporting input/ingress interfaces for flows.
> > > >>
> > > >> Please note that the requirements document only talks about
> > > >> the ability to report it, and not about necessarily reporting
> > > >> them in each record.
> > > >>
> > > >> An argument for not having both as MUST is that in several current
> > > >> router architectures, it would be a big and costly effort to support
> > > >> both. Also our AD directed us to try to standardize "existing
> > > >> practice" and not to require new router architectures for IPFIX.
> > > >>
> > > >> However, there is a clear need for accurate reporting of interfaces
> > > >> on the user side (from which requirements are derived). Reporting
> > > >> on the origin and destination of a packet apparently is very important
> > > >> for many metering-based applications.
> > > >>
> > > >> The positions explicitly stated so far are (please correct me,
> > > >> if I'm wrong):
> > > >>
> > > >>   - Carter proposes having both of them OPTIONAL.
> > > >>   - Paul is fine with the current draft version: bost MUST in general,
> > > >>     but SHOULD for egress in case of multicast.
> > > >>   - Dave seems to have a similar opinion.
> > > >>   - Benoit, Tanja, Sebastian, and myself think that the input/ingress
> > > >>     interface is essential, but that for all output/egress interfaces
> > > >>     a SHOULD would also be sufficient.
> > > >>
> > > >> Are there further opinions?
> > > >>
> > > >>     Juergen
> > > >>
> > > >>
> > > >> --On 15 August 2002 20:40 -0400 Carter Bullard <[email-masked]>
> > > >> wrote:
> > > >>
> > > >>>
> > > >>> Gentle people,
> > > >>>    This is pretty long, I do hope that some find it useful.
> > > >>>
> > > >>> Carter
> > > >>>
> > > >>>> >> 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
> > > >>>>
> > > >>>> I think there is only one exception like that in
> > > >>>> section 6.1.-8. saying that a probe does not need
> > > >>>> to have the ability of reporting the output interface.
> > > >>>> Please note that the same exception holds for the
> > > >>>> input interface.
> > > >>>
> > > >>>
> > > >>> From the perspective of a monitor that is internal
> > > >>> to a switch or a router, the input interface identifier
> > > >>> is historical and factual.  The output interface
> > > >>> identifier is always a predicted value, and as a result,
> > > >>> a guess.
> > > >>
> > > >>
> > > >> As much a guess as packet and octet counters for outgoing
> > > >> traffic in mib-II?
> > > >>
> > > >>>> >> 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.
> > > >>>>
> > > >>>> Since the exception is the same for input and output
> > > >>>> interface, we would consequently have to make the input
> > > >>>> interface OPTIONAL as well, if we follow your argument.
> > > >>>>
> > > >>>> >> 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
> > > >>>> >>
> > > >>>> > You have 2 good examples here.
> > > >>>> >
> > > >>>>
> > > >>>> Flap conditions and load balancing affect the
> > > >>>> input interface as well as the output interface.
> > > >>>>
> > > >>>> >> and port mirrored traffic.  In switches,
> > > >>>>
> > > >>>> I do not see your point concerning port mirrored traffic.
> > > >>>
> > > >>>
> > > >>> Port mirroring in modern switches is generally implemented
> > > >>> in hardware in a half-duplex fashion.  When an ingress
> > > >>> stream of an interface is mirrored, generally, the packet is
> > > >>> latched to the mirrored port, as it is being read, if, of
> > > >>> course, the outgoing port can handle it.  Some vendors
> > > >>> do the same thing with egress port mirroring, hardware
> > > >>> latching both interfaces as the packet is being serialized
> > > >>> out of the box.  There is no status indication available to
> > > >>> indicate whether the mirror port actually received the packet,
> > > >>> or whether the mirror interface is actually up.  The point is
> > > >>> that no monitor could 'realize' whether a particular packet was
> > > >>> actually transmitted to a mirrored interface, given existing
> > > >>> commercial vendor designs.  I've seen customers use egress
> > > >>> interface mirroring for fault tolerance, and for some
> > > >>> of these, they would love for IPFIX to support "multiple egress
> > > >>> interface flow accounting".  I'm not sure that anyone will
> > > >>> ever be able to implement what these words really mean, inside a
> > > >>> switch.
> > > >>>
> > > >>>>
> > > >>>> >> 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
> > > >>>>
> > > >>>> Yes, if I configured the metering process in this way,
> > > >>>> I would expect this. However, it might not be a good idea
> > > >>>> to configure it this way.
> > > >>>
> > > >>>
> > > >>> Well this is the nature of datagram flows in modern switches.
> > > >>> If you are attempting to state what a flow monitor must do in
> > > >>> order to do a decent job, and you decide that egress interface
> > > >>> reporting is going to be a part of that, then you should take
> > > >>> into consideration the normal modes of operation of a modern
> > > >>> switch/router and correctly deal with those conditions.  It
> > > >>> is not a choice of configuration.
> > > >>
> > > >>
> > > >> Well, it is. If I do egress interface reporting, I have the
> > > >> choice of montoring IP only or monitoring both, IP and ARP.
> > > >>
> > > >>>> >> 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?
> > > >>>>
> > > >>>> Same answer.
> > > >>>>
> > > >>>> > Well, for switches (layer 2 devices) I think that we
> > > >>>> shouldn't report
> > > >>>> > any flow records. Only the layer 3 devices should.
> > > >>>> >
> > > >>>> >>
> > > >>>> >> 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?
> > > >>>>
> > > >>>> Wouldn'n these filters be a great location for collecting
> > > >>>> multicast flow information? They anyway maintain a list of
> > > >>>> multicast flows. The requirements suggest to collect
> > > >>>> multicast information saparately for each egress. (And it
> > > >>>> uses only SHOULD, not MUST for multicast traffic.)
> > > >>>
> > > >>>
> > > >>> There is one very fundamental issue here.  While the example
> > > >>> used multicast traffic, the real issue is that switch vendors
> > > >>> provide egress interface filtering for all network traffic.
> > > >>>
> > > >>> Is it better to report that a packet was intended for a
> > > >>> particular interface, whether it was transmitted or not?
> > > >>> Or is it better if the IPFIX monitor is implemented after
> > > >>> all the filters and shapers, such that it doesn't see
> > > >>> all the traffic that the router is dealing with?
> > > >>>
> > > >>> VLANs are almost universally enforced using egress
> > > >>> interface filtering and there are many conditions where
> > > >>> a switch will forward a packet to an interface that doesn't
> > > >>> support a given VLAN, but it filters the packet, doing the
> > > >>> right thing.  Should IPFIX report that the box forwarded
> > > >>> the flow to the interface, unaware that the packets will
> > > >>> be filtered?  Yes that seems reasonable, but you shouldn't
> > > >>> use that record for accounting, because the device didn't
> > > >>> really dispose of the packet in this simple fashion.
> > > >>>
> > > >>>>
> > > >>>> >> Does the IPFIX Data Model need to understand egress interface
> > > >>>> >> filtering behavior for all traffic types or just multicast?
> > > >>>>
> > > >>>> This heavily depends on the list of traffic types for
> > > >>>> which egress filtring is used. I guess you don't use it
> > > >>>> for TCP.
> > > >>>
> > > >>>
> > > >>> Most vendors support filtering for specific TCP flags,
> > > >>> say SYN packets, in their Access Control Lists
> > > >>> and these are almost always implemented as a egress interface
> > > >>> filter.
> > > >>>
> > > >>>>
> > > >>>> >> It may be easier to just make egress interface
> > > >>>> >> reporting an OPTIONAL feature, and then see if
> > > >>>> >> any vendors can successfully implement it.
> > > >>>>
> > > >>>> This holds for most of the requirements.
> > > >>>> But following your arguments: The multicast case
> > > >>>> is not OPTIONAL, but SHOULD in the current reuqirements.
> > > >>>> So, if a vendor faces serious problems implementing it,
> > > >>>> the vendor will drop it. Here we have already what you
> > > >>>> are asking for.
> > > >>>
> > > >>>
> > > >>> I believe that reporting any interface, whether ingress
> > > >>> or egress, should be OPTIONAL.
> > > >>>
> > > >>>>
> > > >>>> All other arguments apply as well to the input interface.
> > > >>>> But you ar not proposing to make this OPTIONAL.
> > > >>>>
> > > >>>> I think one important point behind your arguments is
> > > >>>> that from a router architecture point of view, the most
> > > >>>> obvious pace to locate the observation point and the metering
> > > >>>> process is at the input interface, because similar
> > > >>>> funtionality is required at this location anyway. But when
> > > >>>> doing so it is not always easy to find otu the output interface.
> > > >>>>
> > > >>>> If  a vendor locates the observation points at the output
> > > >>>> interface (what I do not necessarily expect), then it might
> > > >>>> face the inverse problem of not necessarily knowing the input
> > > >>>> interface.
> > > >>>
> > > >>>
> > > >>> If the IPFIX device is monitoring at the egress interface,
> > > >>> then why put the egress id in every record.  It won't change
> > > >>
> > > >>
> > > >> The requirements is not at all about putting something in
> > > >> every packet, it is just about reporting. If the exporting
> > > >> process is able to report once, that all reported flows share
> > > >> the same output interface, then the requirement is already met.
> > > >>
> > > >>> during the life of the monitor.  Since you may not be sure
> > > >>> of the input interface of any packet at the egress interface,
> > > >>> why require that it be reported for any traffic?
> > > >>>
> > > >>>>
> > > >>>> Like Benoit below, I also would like to have more opinions
> > > >>>> on the issue how far the clearly existing requirements by
> > > >>>> metering applications should be loosened in the IPFIX
> > > >>>> requirements document because of assumed limitations of
> > > >>>> today's router architecture?
> > > >>>>
> > > >>>>     Juergen
> > > >>>>
> > > >>>> >>
> > > >>>> > 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.
> > > >>>> >
> > > >>>> >>
> > > >>>> >>
> > > >>>> >> 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/
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> 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/
> >
> > --
> > 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/