[rrg] Locator Path Liveness concerns

[Teco Boot]

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: HeinerHummel at aol.com [mailto:HeinerHummel at aol.com] 
Verzonden: woensdag 10 december 2008 9:42
Aan: teco at inf-net.nl; bill at herrin.us; rja at extremenetworks.com
CC: rrg at irtf.org
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
teco at inf-net.nl:

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: rrg-bounces at irtf.org [mailto:rrg-bounces at irtf.org] Namens
HeinerHummel at aol.com
Verzonden: dinsdag 9 december 2008 21:49
Aan: bill at herrin.us; rja at extremenetworks.com
CC: rrg at irtf.org
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
 
 
 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.irtf.org/pipermail/rrg/attachments/20081210/ac5cc57f/attachment-0001.htm>