Mike & Stewart,
I have a few questions about how you are suggesting handling the
multi-homed prefixes for the IP tunnels with directed forwarding. I am
concerned about the computational requirements.
I believe that your method does essentially destination-based computation
and reduces the number of SPFs from 1 per destination by determining
proxies and assigning destinations to those proxies. For node protection,
this means having using each next-next-hop as a proxy.
For multi-homed prefixes, there isn't a good proxy to use. In your draft,
you suggest either doing a reverse-SPF per multi-homed prefix (or
appropriate group of multi-homed prefixes) or doing another layer of
tunneling to encapsulate the packet to a different router that is
announcing the prefix.
If there are multiple routers announcing the same prefix from an external
region, then this approach seems like it could work. However, if the
prefix is from within the same region, then how do you handle a case such
as the following?
[ S ]-----------[ A ]
5 | | 3
| 1 1 |
[ E ]---[ C ]---[ B ]
5 \ / 10
In this example, if E fails, S would tunneling traffic for prefix X to
B. B will forward it to C. C would then tunnel the traffic back to B.
In this example, there isn't an alternate that can be used; one could add
another router that announces prefix X but is a longer path (or fails
whatever other tie-breaker you may use to decide between it and B).
Without this resolved, the number of SPF computations required seems to be
too many to be realistic for implementation.
Incidentally, I believe that the same multi-homed prefix problem exists for
the RSVP-TE tunnels - with the same concerns on computation.
Rtgwg mailing list