[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Which Side to Control Ingress Link Selection?
- To: Routing Research Group Mailing List <email@example.com>
- Subject: [RRG] Which Side to Control Ingress Link Selection?
- From: Christian Vogt <firstname.lastname@example.org>
- Date: Thu, 6 Mar 2008 11:41:50 +0200
one question that I think is worth being discussed more closely on
this list: Who should have control over which ingress link packets
reach a multi-homed edge network?
(a) the recipient edge network
(b) the sending edge network
(c) the sending edge network when initiating a packet exchange, and
the recipient edge network subsequently
I am asking this question specifically in the context of address
indirection techniques *without* host involvement (such as LISP, APT,
Ivip, Six/One Router), but in principal it also applies to host-based
techniques (such as Shim6, host-based Six/One).
BGP-based traffic engineering, as used today, supports option (a), so it
seems natural to try and support this also in future routing systems.
But if we want to support option (a) with more scalable end-to-end
techniques, such as the exchange of reachability information in LISP,
then we need to ensure that all indirection routers (AKA Six/One routers
or LISP tunnel routers) in an edge network are aware of a remote edge
network's reachability status. The reason is that the egress
indirection router, which processes packets destined to the remote edge
network, is determined by the internal routing system, so it may change
due to traffic engineering.
There are two main options to enable recipient edge networks to select
their ingress links:
(a) Synchronization between indirection routers in the sending edge
network. The recipient edge network must then send its
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.
- Option (a) does not necessarily require continuous synchronization.
may be realized through on-demand synchronization, such as by
multicasting reachability information amongst indirection routers
received from a remote edge network.
- Option (b) has the nice property that it puts the burden of "synchro-
nizing" indirection routers to the edge network that has a benefit
it, namely, to the edge network that is selecting its ingress link.
Would be interesting to hear other folk's opinions on who should have
control over which ingress link packets reach a multi-homed edge
especially from folks working at providers or operators of multi-homed
to unsubscribe send a message to email@example.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