RE: [RRG] Which Side to Control Ingress Link Selection?

[<hannu.flinck@nsn.com>]

 Hello

I am wondering what triggers the egress indirection router 
to require fresh reachability information for a receiving edge? Doesn't
this imply that the receiving edge indicates the need somehow?  

All this sounds quite complicated and fragile if communication between
ingress and egress and mapping system is needed to accomplish something
that is already working through BGP. 

Why not just manage the tunnel end points between egress and ingress
routers? If either of the tunnel end points want to change local their
end point (in an managed way, not due to a failure), they will signal to
their intention to the other end and let the remote side know what would
be the "next" tunnel end point. 

Maybe I am missing something here but how could the sending side know
better what the receiving side wants?


Regards Hannu   

>-----Original Message-----
>From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf 
>Of ext Christian Vogt
>Sent: Tuesday, April 15, 2008 22:14
>To: Scott Brim
>Cc: Routing Research Group Mailing List
>Subject: Re: [RRG] Which Side to Control Ingress Link Selection?
>
>Scott -
>
>Apologies for the delay in responding.  You made very 
>convincing arguments against assuming complete knowledge of 
>other edge net- work's egress indirection routers.
>
>Coming back to the initial problem of whether and how to 
>ensure that packets from a sending edge network take the 
>ingress link selected by the receiving edge network, 
>independent of which egress indirection router of the sending 
>edge network these packets go through, and re-citing the two 
>solution options I stated earlier...
>
>> (a) Synchronization between indirection routers in the sending edge
>>    network.  The recipient edge network must then send its
>>    reachability information to only one indirection router of the
>>    sending edge network, and this would likely be the indirection
>>    router that handles packets in the other direction.
>>
>> (b) Sending reachability information to all indirection routers of a
>>    sending edge network.
>
>...the result of this discussion is then that solution option 
>(a) is preferable because it does not require the receiving 
>edge network to know about all egress indirection routers of 
>the sending edge network.
>
>The synchronization at the sending edge network could happen 
>via multicast, where each egress indirection router joins the 
>multicast group.
>
>The only issue I see with this solution is that there is no 
>convincing incentives model:  Why would the sending edge 
>network pursue the synchronization?  There is a small 
>incentive if we consider fail-over indications from the 
>receiving edge network (e.g., when one of the re- ceiving edge 
>network's providers goes down).  The sending edge network then 
>better informs all egress indirection routers quickly about 
>reachability updates from the receiving edge network.  But if 
>the re- ceiving edge network is sending reachability updates 
>just for local optimization purposes (e.g., load-balancing on 
>ingress links), then the sending edge network has no incentive 
>to spread that information to all of its egress indirection routers.
>
>Finally, for completeness, there is a 3rd solution option, 
>which I haven't mentioned before:
>
>(c)  Assume a pull-based mapping resolution system where mappings
>      are retrieved from the edge network that holds the mapping (e.g.,
>      TRRP or DNS Map).  Then an egress indirection router 
>that requires
>      fresh reachability information for a receiving edge network could
>      perform mapping resolution to determine the receiving edge net-
>      work's preferred ingress link.
>
>Note that this solution option touches the recent discussion 
>on desired properties of mapping resolution systems...
>
>- Christian
>
>
>
>--
>to unsubscribe send a message to rrg-request@psg.com with the 
>word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg