[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