Hi Heiner, 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
