[bmwg] Comments on draft-ietf-bmwg-mcastm-12.txt

["Perser, Jerry" <[e-mail]>]

Here are a few comments:

4.1. Mixed Class Throughput

- Suggest changing 'multicast class frames' to either 'multicast class' or
'multicast frames'.  I could not find in RFC2432 (or elsewhere) the use of
'multicast class frames'.  What is the difference between 'multicast class
frames' and 'multicast frames' ?  Same applies to 'unicast class frames'.

- Suggest changing 'The DUT/SUT MUST learn the appropriate unicast
addresses' to 'The DUT/SUT MUST learn the appropriate unicast and multicast
addresses'.  My experience with DUT is that they DO NOT populate the
forwarding table based on IGMP or ARP messages.  They go from slow path to
fast past after reception of a frame that requires forwarding.

- The search algorithm use to determine the Mixed Class Throughput.  Does it
maintain the multicast to unicast ratio, or can you change the load on one
class only?  My opinion is that you MUST change both classes.  Please
clarity in the I-D.

- When the unicast frames 'transmit in a round-robin fashion', are they to
be in the pattern specified in RFC2889, or ANY round-robin fashion?  There
are several different patterns that fall under 'round-robin'.  Mr.
Mandeville used the one in RFC2889.

- Consider changing 'Total number of multicast groups' to 'Total number of
ingress multicast groups'.  In reporting the 'Total number of multicast
groups', do you sum up the ingress address, or the egress address?  I am
concerned that someone may multiple the groups by the number of egress ports
to get a bigger number.  Other test has this same issues.

4.2. Scaled Group Forwarding Matrix 

- Suggest changing 'The recommended granularity of additional groups to join
per iteration is 10, although the tester MAY choose a finer granularity.' to
'The recommended granularity of additional groups to join per iteration is
10, although the tester MAY choose a different granularity.'  If my DUT has
a capacity of 65K to 512K, I do not want to step by 10 or smaller.  I may
want to step by a 'different' amount.

4.4. Encapsulation/Decapsulation (Tunneling) Throughput 

- Suggest changing 'DUT/SUT or a set of DUTs' to 'DUT/SUT'.  A SUT is a set
of DUTs.

5.1. Multicast Latency

- The paragraph starting with 'End-to-end reachability' is missing.  The
paragraph offered some insight on determining the intent of the
characterization.  Instead of deleting this information, can you change the
first sentence to 'The test monitor MUST verify the correct forwarding of
test traffic by the DUT/SUT prior to the engagement of a test trial.'
End-to-end wording sounded like a network test, not a DUT/SUT test. 

5.2. Min/Max Multicast Latency

- In the reporting format, why MUST the 'set of all latencies' be reflected
in the test report?  I can build hardware to determine this number.  There
may not be an actual 'set of all latencies' stored in the FPGA.  The
hardware will discard the latency values as quickly as it does that actual
frames.  The min/max will be to the procedure, but there will be no 'set of
all latencies'.

6.1 Group Join Delay

- Please put the objective in chronological order.  Consider changing to 'To
determine the time duration it takes from when the DUT/SUT receives an IGMP
group membership report on an interface, to when the DUT/SUT starts
forwarding multicast frames out the same interface.'

- The relationship between state and method is not clear.  I am guessing
that state 0 maps to ONLY method A and state 1 maps to ONLY method B.  This
section looks like two tests jammed under one heading.

One suggestion would be to divide this into two different tests.  Put state
0 and method A under '6.1.1 Initial Group Join Delay'.  Then put state 1 and
method B under '6.1.2 Primed Group Join Delay'.  If there are better
prefixes than 'initial' and 'primed', use them.  This is the best I could
come up with in this short amount of time.

6.2. Group Leave Delay

- Please put the objective in chronological order.  Consider changing to 'To
determine the time duration it takes from when the DUT/SUT receives an IGMP
Leave Group message on an interface, to when the DUT/SUT stops forwarding
multicast frames on the same interface.

8.1. Forwarding Burdened Multicast Latency

- Why 'Perform a baseline measurement of Multicast Latency'?  It is not used
in determining the Forwarding Burdened Multicast Latency.  You can run both
tests for comparison.  The burdened test is a separate test.  Suggest to
remove this.

- Suggest removing 'Similar to Section 5.1, ' in the reporting format.  You
do not need to read Section 5.1 to implement this test.  Everything needed
is already documented here.

8.2. Forwarding Burdened Group Join Delay

- Why 'Perform a baseline measurement of Group Join Delay'?  It is not used
in determining the Forwarding Burdened Group Join Delay.  You can run both
tests for comparison.  The burdened test is a separate test.  Suggest to
remove this.

- Suggest removing 'Similar to Section 6.1, ' in the reporting format.  You
do not need to read Section 5.1 to implement this test.  Everything needed
is already documented here.


Jerry.
_______________________________________________________ 
Jerry Perser                         Spirent Communications
Director of Test Methodology         SmartBits Division 
Phone: [phone]                  26750 Agoura Road 
Lab:   818.676.2337                  Calabasas, CA, 91302 
Cell:  818.292.6457                  Corp:  818.676.2300

  
_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg