> 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.
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 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 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. - R. -- Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- 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
