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

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

Debby Stopp wrote:
> 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
> 

_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg