Subject: Re: [rrg] Locator Path Liveness concerns

From: [email-masked]
Date: Wed, 10 Dec 2008 03:42:19 EST

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-masked]:

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-masked] [mailto:[email-masked]]  Namens
[email-masked]
Verzonden: dinsdag 9 december 2008  21:49
Aan: [email-masked]; [email-masked]
CC:  [email-masked]
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-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 10 Dec 2008 09:59:14 +0100

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-masked] [mailto:[email-masked]] 
Verzonden: woensdag 10 december 2008 9:42
Aan: [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]
Onderwerp: Re: [rrg] Locator Path Liveness concerns

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  

Teco.

-----Oorspronkelijk bericht-----

 
 
Heiner