We should support only one Rx port for each flow about models HOT 11 CLOSED

hmm...i think the different personas who would be interested in testing multicast are

1. Driver developers of switching ASICs - so think say an asic driver developer who has to develop against l2 and l3 mcast in SAI (and they probably don't test it in a nos context), so they will use ASIC SDK to configure the packet replication into the ASIC without any higher layer control protocols, and just want to positive/negative test around packet replication they configured.
2. NOS developers who does control plane protocols, whatever that may be that we don't support yet, and those control protocols will then interact with the ASIC drivers to program the needed l2/l3 replications into the ASIC
3. Users of NOS who wants to deploy anything multicast

It seems a single flow is more natural to describe this replication (in this case is what MulticastPortTxRx could fill the need)

BTW, the above does not mean that these use cases are pressing, i skim through just the file structures for SAI tests, it didn't look like they had tests specifically covering l2/l3 mcast/replication.

As for ashutosh's comment about rx_port_name being optional, I think independent of unicast/multicast, there is always the case of people just want to do Tx and no Rx, and I think we should be open to the possibility that people may want to simply do Rx without Tx also (this is a "measure" first type of scenario that we don't typically consider). And these are the flexibility that PTF/scappy/ixexplorer brings.

from models.

The tx_rx is a choice - right now it supports PortTxRx, DeviceTxRx - the design is meant to be extensible and should support a MulticastPortTxRx for that and have specific documentation in that object as opposed to the PortTxRx

from models.

I agree. I will change the rx_port_names to single rx_port_name.

from models.

Think about multicast? Do we want to model a single flow that will get replicated to two different rx ports as two separate flows?

from models.

Just reopening it for now to make sure we all consider mcast?

from models.

Sounds reasonable.

from models.

@ashutshkumr @ankur-sheth any comments on the way to handle multicast? if you guys also think it is reasonable, we can close this.

from models.

I'm not sure that we want a separate MulticastPortTxRx. That said, multicast doesn't seem like a common use-case. Can you give me an example of a use-case where we are sending/receiving multicast traffic? IGMP?

from models.

Do we need to multicast against:

1. Test ports (traffic engine interface) ?
2. Interfaces belonging to SUT ?
3. Emulated interfaces ?

I'm asking this because we'll need multiple rx port names only for (1.) and the concern is how are we (or who is) going to assign multicast group to each test interface (or if it is even feasible).

Hence, at this point, I do not have enough information to comment on whether we need MulticastPortTxRx.

For (2.), just embedding desired multicast addr in frame should be fine. Interestingly, this also tells us that there are scenarios when we might want rx_port_name to be optional.

(3.) should be taken care of by DeviceTxRx.

from models.

I went thru this thread again. I'm ok to add MulticastPortTxRx if and when required. For now, we are ok to support only one Rx port/device for each flow. We can close it as earlier and open a new issue when we need to support multicast.

@ajbalogh @ashutshkumr @winstonliu1111 sound ok to you?

from models.

sounds good to shelve it, we've got a number of ideas in the discussions if/when this ever comes up again.

from models.