[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 3/18/08 12:36 PM, Christian Vogt allegedly wrote:
>>> 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?

No, it's not a MUST, but we should not design in a way that would make 
it difficult.  If you like I can pull out Feynman's statement about our 
role being to provide a flexible environment for future generations to 
do better than we did. :-)

Even if the ingress and egress points are the same, I think there is 
still a bootstrapping problem here.  Assuming every site does not flood 
information about its mapping points to every other site (shudder!), a 
contacted site cannot be sure to have complete knowledge about a site 
that contacts it.  I suppose that information could be included in the 
initial contact but that's a lot of overhead.  Also, there are potential 
confidentiality problems.  What if a site doesn't want to tell another 
site, a competitor, about its interconnections?  We should not require 
these things.

So even though we don't need to require the ability to have different 
ingress and egress points, we should allow for it, and I believe there 
are problems with a site gaining knowledge about all of the other site's 
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.

It won't know unless (1) it has its own relationship with the receiving 
site, or (2) there is coordination among egress points in the sending 
site, which was your original (a).

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.

A site that initiates communication needs to know one or more possible 
egress points which it is allowed to use.  A receiving demapper only 
needs to know the mapper that is sending traffic to it, nothing else.

Anyway, I would like to agree that if a site wants to coordinate among 
its egress points, that is its own problem, and it shouldn't require 
anything of the receiving site to do so.

Scott

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