I prefer redundancy in the paths also. VRRP or anycast-alike tricks can be used for redundant links to an ISP, redundant firewalls or other kinds of middlebox redundancy.
What I don’t like is to say good-bye to the end-to-end principle. I hope I am not the only one!!! Teco. Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Verzonden: woensdag 10 december 2008 9:42 Aan: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] CC: [email protected] Onderwerp: Re: [rrg] Locator Path Liveness concerns Extending this discussion: The taken path should not only (if at all) be the matter of A and B, instead/mainly the matter of the network. If, while the packet gets forwarded, not only the armed but as well some of the potential alternative destination locations were conveyed, we could even enable that a somehow enforced detour in the middle of the path may cause an exchange between the armed and not-armed destination location in case the latter one is suddenly (due to the detour) the closer one. This would be like a different sort of ANYCAST. In ANYCAST you determine one of several destinations at the ingress and stick to it until you have reached this particular destination, while here the destination selection eventually would be exchanged during forwarding (by exchanging the armed location (of the DFZ router where B is homed). I could show you this by demo code. Heiner In einer eMail vom 10.12.2008 08:48:59 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]: I agree reroute shall not affect application layer, nor the session. On the transmission layer, I doubt. Maybe A could be informed that the <A-a1,B-b1> path is not available anymore. Node A could initiate a <A-a2,B-b1> connection for the same session. A better approach would be set up both connections on forehand and select the best or use load distribution (Mark Handley e.o.). SA based routing to DFZ (e.g. BRDP based routing) circumvents problems with ingress filters and firewalls. There could be other mechanisms monitoring the path between host A and the border routers for A-a1 and A-a2. For example, NTP could be used providing connectivity, delay and jitter statistics to some NTP servers. I think the IGP should validate paths and nodes should be provided accurate information on what source addresses should be used. BRDP does just that. For destination address selection, I don't know how the (local) IGP could help. Teco. -----Oorspronkelijk bericht----- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens [EMAIL PROTECTED] Verzonden: dinsdag 9 december 2008 21:49 Aan: [EMAIL PROTECTED]; [EMAIL PROTECTED] CC: [email protected] Onderwerp: Re: [rrg] Locator Path Liveness concerns I think rerouting inside the path between multi-homed source user A and multi-homed destination user B ought to be possible at which ever point prior getting to B. It may be at A and at any router in the path. It should not involve B nor the application being run at B. And it should not involve the application at A either. Rerouting may either be done such that the packets are still forwarded towards the same destination location, or, if this becomes necessary/advantageous (e.g. for reasons of traffic balancing), that the destination location is changed- e.g somewhere in the middle of the path or at/by the egress router in the first place. Is this a wanted objective ? If so, any architecture, including TARA, needs to do something about it. E.g. a natural approach is to convey an armed destination location as well the potential alternatives while a packet is transmitted. Right ? Heiner
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
