On Fri, Jun 11, 2010 at 9:26 PM, Tony Li <[email protected]> wrote: > Again, function 1 does not make the namespace topologically sensitive. It's > just using a flat identifier space and explicitly learning the location of > the identifier. This is clear if you consider the situation before the host > generates a packet: before the switch learns of the identifier, it has NO > idea where the host is in the network.
So it defaults to repeating the packet to all ports where a router would have chosen to drop the packet. That's the difference between an identifier and a locator? An identifier defaults to flood while a locator defaults to drop? > Function 2 is filtering based on an identifier. Is it now? Last I heard it, different process subscribe to different multicast MACs and can even subscribe to different unicast MACs (e.g. a host OS with guest virtual servers). There's a decision about which process to repeat the packet to. Just like a router, it defaults to not repeating the packet if the destination MAC matches none of the known destinations. > Function 3 is simply including a source identifier. It's only real purpose > is to support the learning function for function 1. Actually, I was talking about the destination MAC that gets tacked on from the ARP table, not the implicit source announcement (much like a route announcement) that lets the switch know which port to repeat subsequent packets to. But hey, you say poTAYto, I say poTAHto and we all dance a little jig. Regards, Bill -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
