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

From: "Carter Bullard" <[email-masked]>
Date: Thu, 15 Aug 2002 20:40:54 -0400

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.

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

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

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 19 Aug 2002 18:51:53 +0200

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

> identifier is always a predicted value, and as a result,

As much a guess as packet and octet counters for outgoing
traffic in mib-II?

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

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

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 23 Aug 2002 13:18:12 +0200

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.
      8. output interface (ifIndex)
         This requirement does only apply to flows for which the
         output interface is included in the observation point.

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Aug 2002 18:29:09 +0200

Juergen,

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

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

---

From: [email-masked]
Date: Fri, 23 Aug 2002 12:47:12 -0400

If I understand correctly, if the observation point
is the output interface then reporting the input interface
is optional. And the other way around. If I got the packet
by some other means, then neither of them are part of the
observation point and thus 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

---

From: Ganesh Sadasivan <[email-masked]>
Date: Fri, 23 Aug 2002 11:58:38 -0700

[email-masked] wrote:

> is optional. And the other way around.

Agreed.

> If I got the packet

Can give an example for the case of  "some other means"?
Ganesh

---

From: David Moore <[email-masked]>
Date: Fri, 23 Aug 2002 13:10:56 -0700

> Can give an example for the case of  "some other means"?

Passive tap in middle of a physical link.

---

From: Ganesh Sadasivan <[email-masked]>
Date: Thu, 29 Aug 2002 12:45:16 -0700

> Can give an example for the case of  "some other means"?

Going by the definition of section 2.2 of requirement spec, a
flow should necessarily be associated with an observation point.
It could be as coarse as the device.
Ganesh