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

From: Juergen Quittek <[email-masked]>
Date: Sun, 11 Aug 2002 03:11:48 +0200

Carter and Benoit,

--On 30 July 2002 14:13 +0200 Benoit Claise <[email-masked]> wrote:

> Carter,
>
>> 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

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.

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

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

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

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

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

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.

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/

---

From: [email-masked]
Date: Tue, 13 Aug 2002 09:45:46 -0400

Conceptual issues tend to cause more problems in the
future than ones of practicality. I don't see a conceptual 
problem here.

I think the SHOULD and MUST of what data to report
ought to refelect today's technology and technology
of the near future.

Given that, our designations for input and output
interface reporting seem reasonable to me.

Paul