Subject: multi-homed prefixes & the IP tunnels approach

From: Alia Atlas <[email-masked]>
Date: Wed, 26 Jan 2005 12:29:01 -0500

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?

                      3
      [ S ]-----------[ A ]
        |               |
      5 |               | 3
        |   1       1   |
      [ E ]---[ C ]---[ B ]
        \               /
       5 \             / 10
          --PREFIX X---

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.

Thanks,
Alia

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg