is that it only covers the problem of
preserving established communications through outages. While this is an
important problem, this is not the only problem with multihoming, and i
would even say that it is not the most important feature that has to be
provided (it is the most difficult/challenging/amusing one, though :-)
I guess that multihoming should provide at least fault tolerance
and traffic
engineering capabilities.
Traffic engineering capabilities are not covered in the document, nor the
impact of one or other approach in the resulting TE capabilities of the
approach.
Fault tolerance features are also broader than the problem of preserving
established communications. Additionally, the problem of establishing new
communications after an outage is relevant (and i would say that
in general
is more relevant than preserving established ones)
So i would argue to perform a broader approach, like the one
provided by JN
chiappa in his multihoming points:
"There are many different potential *goals* one may have for using
multihoming,
e.g.:
- Reliability
- Load balancing
- More optimal paths
- etc
Depending on what one is trying to use multihoming *for*, this may make a
lot
difference to what mechanism(s) (see Obervation #0 about "cost") it makes
sense to use.
[...]
When multihoming is used to provide *reliability*, there are (at least?) 3
different levels of potential capability available. Those 3
classes (in what
appears to me to be the increasing order of difficulty) are:
- Allow new outgoing connections
- Allow new incoming connections
- Keep existing connections open
Again, depending on what level of capability one wishes to provide, the
mechanism used may differ."
I guess that the presented analysis can be extended to also considered the
additional fault tolerance capabilities. for instance it would be required
to add additonal considerations w.r.t these points
Regards, marcelo