Shinta Sugimoto wrote:
Inherent in a scalable multihoming mechanism that separates locators from identifiers is that each host ends up with multiple locators. This means that at least for initial contact, it is the remote peer that needs to select which peer locator to try first. In the case of shim6 this is performed by applying RFC 3484 address selection.This is quite different than the common case of IPv4 multihoming where the site has a single IP address prefix, since in that case the peer performs no destination address selection.Thus in "single prefix multihoming" the site, and in many cases its upstream ISPs, can use BGP to exert some control of the ingress used to reach the site. This capability can't easily be recreated in "multiple prefix multihoming" such as shim6.I am not sure if I understand the above texts correctly, but my interpretation of above texts is that the host centric approach (or the concept of id-locator split) of SHIM6 in which a host should deal with multiple locators at a time has implications on source & destination address selection to be done by the end nodes.
Yes, but that isn't a property of "host centric" - it is a property of any scheme that would have multiple prefixes for a multihomed site (even for instance if the multiple prefixes are handled by some routers/proxies at the site boundaries). You end up with multiple addresses in the DNS so that the initial contact can be robust against a single failure.
In contrasts, under single prefix multihoming environment, there is no such requirements for the end nodes but routers inside the network are required to somehow manage routing information so that the IP packets destined to the node which has IP address derived from the multihomed prefix. But,, I wonder how this relates to Traffic Engineering. I should admit that I don't have deep insight into Traffic Engineering, though.
It does have implications on traffic engineering.But any scalable multihoming approach needs to have multiple prefixes for a site in order to avoid a route in the Default-free zone for every multihomed site. So as a first order approximation, this impact on TE is fundamental to the problem we are trying to solve and not specific to shim6.
There are differences on how a site administrator or an ISP can influence the locators that are used, for instance Mike O'Dell's original GSE proposal has locator rewriting as a way for routers to influence the choice *after* the first packets have been exchanged. I don't know if such a capability would be useful for shim6.
o Some heuristic on A or B (or both) determine that it might make sense to make this communication robust against locator failures. For instance, this heuristic might be that more than 50 packetss/heuristic/heuristics/Singular form is without the 's' AFAIK.I am not a native English speaker but my dictionary says that "heuristic" is adjective and "heuristics" is noun (uncountable).
Neither am I. But the dictionary doesn't seem to match common computer science usage. "a heuristic" is used in http://en.wikipedia.org/wiki/Heuristic_%28computer_science%29
Erik