RE: [bmwg] logic problem in RFC 3918

["Rajiv Asati (rajiva)" <rajiva at cisco.com>]

Hi Dave,

You have brought up an interesting issue. 

> Most (though perhaps not all) switches will flood multicast 
> traffic when
> the test instrument attempts to join more groups than the DUT/SUT can
> handle.

Could you please elaborate? A sane multicast implementation should not
let the multicast traffic be forwarded on the interface that didn't
participate on a particular multicast tree.

This, of course, is orthagonal to IGMP snooping capability that is
common on layer2 devices.


But as I read section 7.1, I find it a bit left for interpretation. For
example, 
the below excerpt from procedure -

...
   If at least one frame for each multicast group is forwarded properly
   by the DUT/SUT on each participating egress interface, the iteration
   is said to pass at the current capacity.
...

If the DUT receives 1000 frames for each multicast group from the
source, then one interpretation of the above excerpt is that the receipt
of one or more frames (out of 1000 frames) would qualify the case as
"success". 

AFAIK, the DUT must forward 1000 frames on each participating egress
interface for the success. 

Cheers,
Rajiv

> -----Original Message-----
> From: David Newman [mailto:dnewman at networktest.com] 
> Sent: Wednesday, December 19, 2007 5:17 PM
> To: bmwg at ietf.org
> Subject: [bmwg] logic problem in RFC 3918
> 
> The multicast group capacity test (RFC 3918, section 7.1) says an
> iteration passes if "at least one frame for each multicast group is
> forwarded properly by the DUT/SUT on each participating 
> egress interface."
> 
> That word "properly" is a problem; as the test is currently written,
> there's no way to verify it.
> 
> Most (though perhaps not all) switches will flood multicast 
> traffic when
> the test instrument attempts to join more groups than the DUT/SUT can
> handle.
> 
> A flooded frame looks exactly the same as a non-flooded one. Since an
> RFC-compliant test can be performed with as little equipment as one
> ingress and one egress interface (indeed, that's explicitly 
> stated in at
> least one commercial implementation), the test instrument 
> cannot detect
> that the DUT/SUT is flooding, and will still pass that iteration.
> 
> A test with 1000 egress interfaces also will incorrectly pass if
> receivers on all 1000 interfaces join the same groups and 
> flooding occurs.
> 
> Two possible fixes:
> 
> 1. Add one or more monitor ports to the test, and fail any 
> iteration in
> which the test instrument receives multicast test traffic on 
> the monitor
> port(s). This is conceptually similar to the setup in RFC 
> 2889's address caching capacity test.
> 
> 2. Configure the test instrument so that each egress interface joins a
> different set of multicast groups. Fail any iteration in 
> which multicast
> traffic is not forwarded properly (in this case, shows up on the wrong
> egress interface).
> 
> Of these two, I strongly prefer option 1. It allows for tests 
> with more
> fan-out and, in L3 scenarios, more mroutes. Both of these are more
> stressful on the DUT/SUT.
> 
> dn
> 
> 
> 
> 
> _______________________________________________
> bmwg mailing list
> bmwg at ietf.org
> https://www1.ietf.org/mailman/listinfo/bmwg
> 

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