[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Which Side to Control Ingress Link Selection?
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
(a) is agreed, and you're pondering (c) ...
Actually, I do not prefer (c) over (a). But (c) is a necessary
consequence of certain types of mapping resolution systems, via which
sending edge networks initially retrieve address mappings: (a) is
possible with mapping resolution systems that can tag mappings with
preference values, because the preference values are set by the
mapping owner who in this case is the recipient edge network. But if
there is no way to indicate mapping preferences during mapping
resolution, then the sender will have to select a mapping initially,
and we end up with a solution for (c).
There are two main options to enable recipient edge networks to
their ingress links:
(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 problem with (b) is that the destination site will not know all of
the source site's egress points. Ingress and egress points do not
have to be the same. The destination site can only respond to queries
it receives. It is up to the source site if it wants to coordinate
among its egress points.
Do you think that it is a must for any solution to enable differing
sets of ingress points and egress points?
- Option (a) does not necessarily require continuous
It may be realized through on-demand synchronization, such as by
multicasting reachability information amongst indirection routers
once 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
benefit from it, namely, to the edge network that is selecting its
But the problem being solved is optimizing the source site's egress
point. The destination site already solved its problem: traffic
enters where it wants.
No, it does not. See my initial mail: If the internal routing system
in the sending edge network changes the egress point, the new egress
indirection router won't know which ingress point is preferred by the
receiving edge network. This is why there needs to be a way of
coordinating indirection routers of the sending edge network.
In any case I don't think this idea, of having all sites maintain
knowledge of all other sites' interconnect points, is going to scale
They already have to. Note that we are talking only about the
interconnect points of edge networks with which there are active
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