Dear Noel,

As I know, the original rationale for RRG was to find a solution to
mitigate the DFZ routing table explosion. LIS like ILNP was then proposed
as a solution mechanism.

One might argue that LIS does not help reduce the DFZ routing table size;
please find the attachment. If there's any point in the argument, then
we've not accomplished our original task wrt DFZ routing table explosion,
echoing your point.

On Sat, Nov 10, 2012 at 12:29 PM, Noel Chiappa <j...@mercury.lcs.mit.edu>wrote:

>     > From: Tony Li <tony...@tony.li>
>
>     > The publication of these RFCs concludes our long standing work item
> on
>     > a revised routing architecture.
>
> Separation of location and identity is very desirable, but it has basically
> nothing to do with routing (other than removing identity functionality from
> the names used for routing, making them a bit more tractable).
>
> We still have the same old kludgy BGP global routing system we always had,
> and _nothing_ has been proposed to improve/replace it.
>
>     > The group has ... helped push the boundaries of routing farther
>     > forward.
>
> Nonsense. It has produced no routing work at all.
>
>         Noel
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg
>



-- 
DY
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.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to