[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@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg