Provider Selection and Mapping Updates (Re: [RAM] Re: the separation of ID/RLOC)

[Christian Vogt <christian.vogt at nomadiclab.com>]

Iljitsch:

>> You are raising an interesting point.  The process of detecting
>> failure of a provider may indeed be a bottleneck today.
> 
> Actually, this is the easy part, because you can simply send hello 
> packets at a pretty high rate across a link. Or even better: let a 
> watchdog timer go off when no packets have been received for a
> certain time. The latter has the advantage that you don't need to
> inject keepalives when there is real traffic and you aren't bound by
> round trip time speed. (Which isn't too bad for a single layer 2 link
> in almost all cases, though, especially if you can get rid of the
> variability by bypassing any queues for the keepalives.)
> 
> But we were talking end-to-end, or at least across a number of links.
>  This means the keepalive traffic explodes and there are no longer
> any interface-specific tricks that can be done for optimization.

But end-to-end keepalives are not the only solution to update remote
mapping functions.

E.g., the solution that I was having in mind is to put the edge network
in charge of selecting one of the providers it connects to.  This edge
network can find a working provider efficiently due to the topological
vicinity (as you also mentioned above).  If a provider change is needed,
mapping functions in remote edge networks can be updated on demand.

This idea does not work equally well for all architectural approaches:

- The idea is incompatible with pure host-based solutions such as Shim6,
where effectively hosts are in charge of provider selection (by choosing
IP source addresses from a specific provider).

- The idea can be realized with pure network-based solutions such as
LISP/Ivip.  The problem that remains in this case is to update remote
mapping functions /efficiently/ since the number of to-be-updated
mapping functions is large (it potentially equals the number of edge
networks).

- The idea naturally fits together with combined host/network-based
solutions such as Six/One.  Moreover, you avoid the problem of
cumbersome mapping function updates in this case.  The reason is that
the to-be-updated mapping function is with the correspondent host, and
such a mapping function gets updated automatically (and implicitly,
without extra signaling) based on the regular packet exchange.

- Christian

PS:  I'll respond to the rest of your email in a separate message.




_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram