Hi Roland,
> I don't think that ILNP will work out of the box if two > nodes have the same ID but are located in different subnets. > The transport cannot distinguish whether it's a connection > to itself or to the other remote system if it only operates on the ID. > I think that the problem of conflicting IDs but different Locators > is probably solvable, but I haven't seen any proposal for this so far. As I just mentioned, this is easy if they are locally generated IDs. There are specific bit patterns that indicate a locally generated ID and the transport will need to demux on the full address in this case. As with any locally generated ID, mobility to arbitrary other locators cannot be supported. > Hmm, when considering the increasing use of virtual hosts, we > may get in trouble here: virtual hosts probably don't have a unique > hardware ID and usually generate a MAC address (or multiple ones > in case of several virtual interfaces) at installation time. If we take the example of VMware, a virtual host will end up with a pseudo-random address in 00:0c:29, and can create collisions with other VMware installations, in which case you have to set the MAC address locally. Pretty clearly, folks are abusing basic Ethernet and ILNP cannot fix that. Using a locally generated MAC would be the right approach here. > As long as you have the Locator in addition to the ID available, > that's ok, but as far as I understood, the transport layer only > uses I. So further demultiplexing will only work if the transport > layer considers L:I together. Is this the case somewhere, e.g., when > passing packets to the network layer? The transport will need to use L:I for locally unique IDs. Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
