Let us summarize the argument for LIS:

 o Symptom: The DFZ routing table is exploding.
 o Primary Diagnosis: Incompetence in multihoming is the cause.
 o Secondary Diagnosis: Semantic overloading of IP address is responsible for multihoming incompetence.
 o Prescription: Apply LIS.

We argue that LIS is a wrong prescription to the problem of the DFZ routing table explosion.

Let us ask ourselves the following question:

 o Does LIS improve multihoming?

Our focus would be on the locators, an outcome of LIS. The DFZ routing table explosion will not go away unless locators are aggregatable. To be aggregatable, the locators have to be provider-aggregatable(PA). With multiple Internet service providers(ISPs) serving your site in multihoming, which PA locator sets should you load your client nodes, all of them or either of them? Your preference would be to use provider-independent(PI) locators and be free of the managerial headache with multiple PA choices. This is the same situation with IP addresses; no change and so no improvement.

How about ISP migration which is a degenerate case of multihoming? You have to renumber your locators whenever you're to migrate to a different ISP. Renumbering is so painful that no network managers would like to do. Your preference again would be to use PI locators to avoid renumbering; the same situation with IP addresses and so no improvement.

That is, switching to locators does not improve your competence in multihoming, hence does not contribute to mitigation of the DFZ routing table explosion. LIS is a wrong prescription.

If LIS is not the right solution, it follows that blaming the contextual overloading of IP address is ill grounded. Contextual overloading of IP address is not responsible for DFZ routing table explosion.