routing table go boom

Wed Mar 20 05:40:11 UTC 2013

Dobbins, Roland wrote:

> But if one insists on viewing it through the prism of the
> end-to-end principle, LISP adheres to it more than does
> the current routing system.

It merely means you are using a wrong prism.

Let's consider a very basic multihoming with two locators,
one of which is blackholed.

Then, how can an ITR, which initially choose a blackholed
locator, know that the locator is not working and fall
back to another locator?

In general, we should assume protocol used is something
unknown to the ITR (not TCP, of course) and/or not assume
the ITR is on return path so that the ITR can't have any
"knowledge" that an end system receiving any reply.

In this case,

   The function in question can completely and correctly be
   implemented only with the knowledge and help of the
   application standing at the endpoints of the communication
   system.

means only the higher stack of the end system have "the knowledge"
that sent packets are not replied.

But, the end system can't "help" the ITR, because it does not
even know the ITR exist.

Therefore,

   Therefore, providing that questioned function as a
   feature of the communication system itself is not possible.

providing that questioned function of destination locator
selection for multihoming as a feature of ITR is not possible.

> Anyway, I'm done feeding this particular troll for good.

Use a looking glass to see a troll.

Always check the original paper to avoid wrong interpretations
of yours.

						Masataka Ohta

PS

Is it time to shutdown LISP WG?