> > A quibble about multicast - AFAIK this is unsolved. I > think some spec > needs to be agreed that documents what > sort of multicast snooping > operations switches need to do, > ie if IGMP joins imply that IBoE > traffic for the same DMAC > is included in the join, or if IBoE requires > a seperate > IGMP type process on its own ether-type. That would make it > > much clearer what to do with MGIDs. >
It would be quite naïve to require *new* snooping functionality in Eth switches. Some switches will gracefully apply to non-ip traffic the filtering information acquired through IGMP snooping. And some will just flood non-ip MC frames within the corresponding VLAN which is benign (e.g. that is the way FIP works). A cleaner solution would be based on MMRP but that, AFAIK, is not very widely deployed so it is less practical at this stage. > I agree -- the current spec is rather broken for multicast. > Choosing a different ethertype and then saying that all > switches will just flood multicast traffic is half-baked at best. > It is a realistic approach. Do you claim that there are switches that will not forward the packets? > > It would be nice to at least have a plan on how to > integrate a > non-link local address, if that is ever > necessary in future. An > extended AH with an additional 48 > DMAC field seems reasonable to me? > > You mean have a next-hop destination + a final destination? > Could be done I guess. But I'm not sure how having a routing > table where you have to look up 48-bit Ethernet addresses is > all that different from just having a standard Ethernet > forwarding table. I guess Jason suggests regarding the GID as a true L3 address and using a new added L2 field for the next hop L2 address. > > I suppose something based on MAC-in-MAC (a la 802.1ah) could > be done but to be honest the IBoE spec that the IBTA came up > with looks rather broken for routing. Routing is out of the scope of the current RoCE spec. And I do not see how .1ah would be relevant for this purpose. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
