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

[Christian Vogt <christian.vogt@nomadiclab.com>]

Scott -

> > 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  
> > select
> > 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?

> > Two comments:
> >
> > - Option (a) does not necessarily require continuous   
> > synchronization.
> >  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  
> > has  a
> > benefit from it, namely, to the edge network that is selecting  its
> > ingress link.
>
> 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
> very well.

They already have to.  Note that we are talking only about the
interconnect points of edge networks with which there are active
packet exchanges.

- 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