> From: John Day <jeanjour@xxxxxxxxxxx>
> Multihoming is fundamentally a routing problem.
I have been thinking this for some time too, and it's especially true/clear
when the multi-homing in question is site multi-homing, and not
host-multihoming (which is much rarer, is my impression). You clearly have
two alternative paths to the destination, and have to pick.
Which raises the question of 'why not have the routing do it', and that's a
very valid question. In a routing architecture which had better - read
non-manually configured - _scopes_ for routing information, and more
automatic aggregation (or hiding, to use the more general concept), I think I
would agree that probably it should be hidden in the routing. (The "probably"
is because I'd have to see the actual details.)
However, we have to 'go to war with the army we have', and the current routing
architecture (which includes the _functional interface_ with the _rest_ of the
architecture, not just how it's arranged internally - and the former is
basically impossible to change) makes it impossible to do that.
> It is a problem of routing not be able to recognize that two points of
> attachment go to the same place. Portraying it as anything else is just
> deluding yourself.
I would agree with this, except I defer to the 'get down off an elephant'
principle. If both points of attachment are bound to a single transport level
entity, then it ought to be relatively easy, and not involve the routing at
all, to detect that both points of attachment lead to the same entity.
Noel
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf