Subject: re: [bmwg] draft-ietf-bmwg-mcastm-11 Join Test(Section 6.1)

From: Debby Stopp <[email-masked]>
Date: Wed, 23 Apr 2003 15:07:49 -0700

All -

Although the discussion of the inner workings of a router or a switch may be
interesting to some, it falls outside the scope of the BMWG.  

From a black box testing perspective, there are two test metrics where 'join
delay' would be interesting:

 1) Starting from a clean slate, state 0, address not present in the MFDB.
   In this scenario, the metric represents the time the DUT takes to add the
address to the MFDB and begin forwarding the multicast packet.

 2) The address is already present in the MFDB, as there is one or more
egress ports that have previously joined and are currently receiving
multicast packets.
    In this scenario, the metric represents the time the DUT takes to update
the MFDB and begin forwarding the multicast packet to the newly joined
egress port<s>.

The current methodology only addresses the first metric, however I believe
both metrics have merit.  With very little modification to the existing
text, the join delay methodology can be modified to allow the user community
the flexibility to select the type of metric they prefer to collect.

Debby

jerry wrote:
> I am not sure L2/L3 switches work the way you describe them.
> Analyzing the
> packet is simply if it is not in the FDB, then send it to the CPU. The
> "writing the layer 2 header + replicating the packet for 
> subsequent group
> joins" are handled by hardware ASICs.
> 
> The problem is that frames not in the FDB go to the CPU for
> processing.
> This includes the first unicast/multicast frames to a flow,
> unicast/multicast with no route, and control plane frames 
> (ARP, IGMP, OSPF,
> BGP4, etc.).
> 
> Brooks was trying to prevent a DOS type attack on the CPU so
> that it can
> handle the IGMP frame quickly and give an accurate Group Join Delay
> measurement.
> 
> I would like to hear from any of the switch vendors on the
> reflector.  Does
> your box handle multicast frame replicating in hardware or by 
> the CPU?  Is
> IGMP membership reports hardware or CPU?
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Kevin Dubray <[email-masked]>
Date: Wed, 23 Apr 2003 18:27:04 -0400

As mentioned earlier, RFC 2432 doesn't constrain the context in which to
collect this join delay metric.

Moreover, both contexts you cite could be very insightful, so at first 
blush,
I see nothing wrong with accommodating both contexts.  If I follow, the
implication is that each context requires a different methodology.

If this holds, you'll need to make sure the context gets reported in the
results.

-Kevin

---

From: Kevin Dubray <[email-masked]>
Date: Wed, 23 Apr 2003 18:27:04 -0400

-Kevin