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

From: Christian Vogt <[email-masked]>
Date: Thu, 6 Mar 2008 11:41:50 +0200

Folks,

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

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.

Would be interesting to hear other folk's opinions on who should have
control over which ingress link packets reach a multi-homed edge  
network,
especially from folks working at providers or operators of multi-homed
edge networks.

- Christian

--
to unsubscribe send a message to [email-masked] 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

---

From: "William Herrin" <[email-masked]>
Date: Thu, 6 Mar 2008 09:26:36 -0500

>  seems natural to try and support this also in future routing systems.

Hi Christian,

Actually, BGP supports (a) when the packet is near the recipient, (b)
when the packet is near the sender and (d) [ISP traffic engineering]
when the packet is in between. Everybody gets to tweak the path.

Regards,
Bill Herrin

-- 
William D. Herrin                  [email-masked]  [email-masked]
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Christian Vogt <[email-masked]>
Date: Thu, 6 Mar 2008 16:58:40 +0200

Hi there -

> when the packet is in between. Everybody gets to tweak the path.

Certainly.  I was focussing on the part near the recipient, though:
the selection of an edge network's ingress link.  This part is where
BGP-based traffic engineering supports (a) and only (a).

- Christian

---

From: Brian Dickson <[email-masked]>
Date: Thu, 06 Mar 2008 12:37:00 -0500

> (a) the recipient edge network
[snip]
> network's reachability status.
[snip]
> (b)  Sending reachability information to all indirection routers of a
[snip]
>   nizing" indirection routers to the edge network that has a benefit from

This segues nicely into a discussion on how to scale reachability 
distribution.

I touch on it a bit in draft-dickson-rrg-v6dh, section 1.1.4.2 (Edge 
reachability - routing announcements).

Here's the basic problem: reachability on any indirection router, is 
generally aggregated
into reachability of a PA block in BGP. This effectively hides the 
specific reachability
of individual indirection router.

Directly sharing reachability information (in the positive sense, "I am 
reachable") between indirection
routers, is a huge N^2 problem, where the previous-discussed long-term 
estimates on N are on the order of 10^8 or more.

Consider the following (imperfect) analogy:

In the early days of AM (amplitude-modulation) wireless (radio) 
transmission, the "signal" was combined with the "carrier",
and the resulting mixture was amplified and transmitted.

Most of the energy in the system went into the "carrier", resulting in 
very poor performance.

When the trick of suppressing the carrier signal itself from the 
combined signal, all of the energy went into the side-bands.
Suppressing one of the two side-bands, resulted in Single Side-Band, or 
SSB, radio. This allowed high-power radio
to be commercially viable.

The analogy I'm getting at is this: the default reachability state is 
carried by the "carrier", which is the BGP PA prefix.
If the PA block is reachable, the presumption generally is that the 
indirection router is reachable.

Then, the only additional information needed, is to distribute 
information on whether and when, indirection routers
are *unreachable*.

Note Well: not every more-specific edge router within a PA block will be 
an indirection router. The key comparison
that needs to be done is whether the general percentage of PA 
more-specifics that are indirection routers, times the
percentage of more-specific routers that are currently unavailable, is 
on par with or lower than, the aggregation factor
for PA blocks generally. Note also that in some instances, there may be 
some ability to aggregate unavailable more-specifics.

If the number of (aggregated) indirection routers that are unavailable, 
is smaller than the number of PA blocks, or at least of
the same order of magnitude, then this approach may be worth pursuing.

The scalability of, and mechanisms for, distributing this information is 
something that likely fits well into BGP.

At the edge, from the BGP speaker to indirection routers, sending state 
information on reachability, might fit well into some
kind of multicast scheme. E.g. join one multicast group to receive a 
full table, join another to receive updates, and once state
is synchronized via the full table, exit the full-table group. This 
scales well enough, presuming the availability of multicast - something
that is pretty much a requirement for IPv6, it could be observed.

Within the BGP system, a new AFI/SAFI would likely be needed to opaquely 
pass the state.

The opaqueness means it would pass through the global DFZ, without being 
used by DFZ routers (e.g. in their RIBs).
And the mechanisms to trigger unreachability announcements are pretty 
much orthogonal to the existence of such
annoucements.

> control over which ingress link packets reach a multi-homed edge network,
To use an oft-quoted expression, "routing sucks". Meaning, routing 
advertisements
attract traffic, and only in the presence of routes does traffic get to 
its destination.

My opinion is that, notwithstanding philosophical issues, the recipient 
is ultimately
in control by virtue of being able to withdraw announcements. So, from a 
pragmatic
perspective, it makes most sense to view (a) as the default choice.

It also matters that, for the most part, the recipient pays for delivery 
of packets.

Hot-potato routing means ISP(sender) throws the traffic to the 
ISP(recipient)
as soon as possible, meaning ISP(recipient) usually bears most of the 
long-haul costs.
This in turn gets passed on to the recipient, in the form of the billing 
model for traffic.

Brian Dickson

---

From: Scott Brim <[email-masked]>
Date: Thu, 6 Mar 2008 15:58:53 -0500

>     the recipient edge network subsequently

(a) is agreed, and you're pondering (c) ...

> There are two main options to enable recipient edge networks to
> select their ingress links:
> 
>     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.
> 

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.

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

> Would be interesting to hear other folk's opinions on who should
> have control over which ingress link packets reach a multi-homed
> edge network, especially from folks working at providers or
> operators of multi-homed edge networks.

I like Bill's answer, with a few extra details above.

swb

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Mar 2008 14:18:41 +1300

> BGP-based traffic engineering supports (a) and only (a).

I wonder if this is a problem that will still exist in future?
In a world with maps distributed in the way we're discussing,
single-ended ingress or egress selection seems to vanish as an issue;
the issue is how to choose an egress/ingress pair that has
desirable path chararacteristics.

   Brian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 18 Mar 2008 18:34:04 +0200

Brian -

> My opinion is that, notwithstanding philosophical issues, the
> recipient is ultimately in control by virtue of being able to withdraw
> announcements. So, from a pragmatic perspective, it makes most sense
> to view (a) as the default choice.

This is a very good point.

> It also matters that, for the most part, the recipient pays for
> delivery of packets.

Right, this is the beauty of approach (a):  Each side selects from
those providers which it has to pay:  The sending edge network selects
the local egress provider, and the receiving edge network selects the
local ingress provider.

> ISP(recipient) as soon as possible, meaning ISP(recipient) usually
> bears most of the long-haul costs.

Could you elaborate more on this?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 18 Mar 2008 18:36:27 +0200

Scott -

> (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).

> it receives.  It is up to the source site if it wants to coordinate

Do you think that it is a must for any solution to enable differing
sets of ingress points and egress points?

>> synchronization.
>>  It may be realized through on-demand  synchronization, such as by
>> once received from a remote edge  network.
>>
>>  "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.
>
> 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

---

From: Christian Vogt <[email-masked]>
Date: Tue, 18 Mar 2008 18:44:41 +0200

Brian -

> desirable path chararacteristics.

Doesn't the issue persist independent of the characteristics based on
which a path gets selected?  Independent of *how* a path gets selected,
you need to decide *who* selects it (or who selects which part of it).

- Christian

---

From: Pierre Francois <[email-masked]>
Date: Tue, 18 Mar 2008 13:15:56 -0400

Brian,

Brian Dickson wrote:
> ISP(recipient) as soon as possible, meaning ISP(recipient) usually bears most of the 
> long-haul costs. This in turn gets passed on to the recipient, in the form of the billing 
> model for traffic.

I may misunderstand this statement, but to me this is true for only half 
of the path.

Once packets crossed a peering link or start to go down along 
provider->customer peering links, hot potato is not necessarily a fact.

A customer can impact the Local-pref value of the paths it advertises to 
its provider using the communities agreed upon with the provider

A customer can use prepending

A customer can use MED

If none of the above techniques are used then and only then hot potato 
will play a role. I pay my providers to carry my bits after all...

Cheers,

Pierre.

---

From: <[email-masked]>
Date: Wed, 19 Mar 2008 10:25:05 +0200

It looks to me that in addition to "how" and "who" there is also a
question of "what". 
What kind of path is to be selected among the alternative paths. This
implies that who ever selects a path needs to know about path
characteristics in the underlying inter domain routing system. 

It may be that the priorities and weights that some of the mapping
solutions provide need to still respect the routing policies of the core
or at least be aware of them.  

Regards Hannu  

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of ext Christian Vogt
>Sent: Tuesday, March 18, 2008 18:45
>To: Brian E Carpenter
>Cc: William Herrin; Routing Research Group Mailing List
>Subject: Re: [RRG] Which Side to Control Ingress Link Selection?
>
>Brian -
>
>> the issue is how to choose an egress/ingress pair that has desirable 
>> path chararacteristics.
>
>
>Doesn't the issue persist independent of the characteristics 
>based on which a path gets selected?  Independent of *how* a 
>path gets selected, you need to decide *who* selects it (or 
>who selects which part of it).
>
>- Christian
>
>
>
>--

---

From: Scott Brim <[email-masked]>
Date: Wed, 19 Mar 2008 14:27:13 -0400

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

>>>  "synchro- nizing" indirection routers to the edge network that has  a

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

> interconnect points of edge networks with which there are active

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

---

From: Scott Brim <[email-masked]>
Date: Wed, 19 Mar 2008 14:36:46 -0400

> or at least be aware of them.  

In LISP we discussed the possibility of including a "higher layer 
payload type" indicator in the Map-Request, for use in deciding what to 
send in a Map-Reply.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Mar 2008 14:07:21 +1300

Hi Christian,

> you need to decide *who* selects it (or who selects which part of it).

Well, that's true of course. But nothing can change the fact
that the originating host chooses the source address and destination
address that the packet starts out with, and all subsequent choices
depend on that.

     Brian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Apr 2008 22:13:35 +0300

Scott -

Apologies for the delay in responding.  You made very convincing
arguments against assuming complete knowledge of other edge net-
work's egress indirection routers.

Coming back to the initial problem of whether and how to ensure
that packets from a sending edge network take the ingress link
selected by the receiving edge network, independent of which egress
indirection router of the sending edge network these packets go
through, and re-citing the two solution options I stated earlier...

> (b) Sending reachability information to all indirection routers of a

...the result of this discussion is then that solution option (a) is
preferable because it does not require the receiving edge network to
know about all egress indirection routers of the sending edge network.

The synchronization at the sending edge network could happen via
multicast, where each egress indirection router joins the multicast
group.

The only issue I see with this solution is that there is no convincing
incentives model:  Why would the sending edge network pursue the  
synchronization?  There is a small incentive if we consider fail-over
indications from the receiving edge network (e.g., when one of the re-
ceiving edge network's providers goes down).  The sending edge network
then better informs all egress indirection routers quickly about
reachability updates from the receiving edge network.  But if the re-
ceiving edge network is sending reachability updates just for local
optimization purposes (e.g., load-balancing on ingress links), then
the sending edge network has no incentive to spread that information
to all of its egress indirection routers.

Finally, for completeness, there is a 3rd solution option, which
I haven't mentioned before:

(c)  Assume a pull-based mapping resolution system where mappings
      are retrieved from the edge network that holds the mapping (e.g.,
      TRRP or DNS Map).  Then an egress indirection router that requires
      fresh reachability information for a receiving edge network could
      perform mapping resolution to determine the receiving edge net-
      work's preferred ingress link.

Note that this solution option touches the recent discussion on desired
properties of mapping resolution systems...

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Apr 2008 22:16:22 +0300

Brian,

fully agree, but my point is that our new routing architecture may give
more control to the sender:  By selecting a transit address in addition
to an edge address, the sender will be able to fix an intermediate
point on the route towards the receiver.  Thereby, it will be able to
select the ingress link at the receiving edge network.  Today, it is the
/receiving/ edge network that selects the ingress link -- through BGP.

- Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2008 10:09:25 +1200

> /receiving/ edge network that selects the ingress link -- through BGP.

Well, we'd need to understand why there might be a change to the very
old reluctance to pass any kind of topological knowledge to the host.
Up to now, hosts have been strictly address-driven, and treated the
network as an opaque cloud with no internal topology. Do you think
that will change?

    Brian

---

From: <[email-masked]>
Date: Wed, 16 Apr 2008 10:59:26 +0300

Hello

I am wondering what triggers the egress indirection router 
to require fresh reachability information for a receiving edge? Doesn't
this imply that the receiving edge indicates the need somehow?  

All this sounds quite complicated and fragile if communication between
ingress and egress and mapping system is needed to accomplish something
that is already working through BGP. 

Why not just manage the tunnel end points between egress and ingress
routers? If either of the tunnel end points want to change local their
end point (in an managed way, not due to a failure), they will signal to
their intention to the other end and let the remote side know what would
be the "next" tunnel end point. 

Maybe I am missing something here but how could the sending side know
better what the receiving side wants?

Regards Hannu   

>Sent: Tuesday, April 15, 2008 22:14
>To: Scott Brim
>Cc: Routing Research Group Mailing List
>Apologies for the delay in responding.  You made very 
>convincing arguments against assuming complete knowledge of 
>other edge net- work's egress indirection routers.
>
>Coming back to the initial problem of whether and how to 
>ensure that packets from a sending edge network take the 
>ingress link selected by the receiving edge network, 
>independent of which egress indirection router of the sending 
>edge network these packets go through, and re-citing the two 
>solution options I stated earlier...
>
>...the result of this discussion is then that solution option 
>(a) is preferable because it does not require the receiving 
>edge network to know about all egress indirection routers of 
>the sending edge network.
>
>The synchronization at the sending edge network could happen 
>via multicast, where each egress indirection router joins the 
>multicast group.
>
>The only issue I see with this solution is that there is no 
>convincing incentives model:  Why would the sending edge 
>network pursue the synchronization?  There is a small 
>incentive if we consider fail-over indications from the 
>receiving edge network (e.g., when one of the re- ceiving edge 
>network's providers goes down).  The sending edge network then 
>better informs all egress indirection routers quickly about 
>reachability updates from the receiving edge network.  But if 
>the re- ceiving edge network is sending reachability updates 
>just for local optimization purposes (e.g., load-balancing on 
>ingress links), then the sending edge network has no incentive 
>to spread that information to all of its egress indirection routers.
>
>Finally, for completeness, there is a 3rd solution option, 
>which I haven't mentioned before:
>
>Note that this solution option touches the recent discussion 
>on desired properties of mapping resolution systems...
>
>- Christian
>
>
>
>--

---

From: [email-masked]
Date: Thu, 17 Apr 2008 14:44:26 EDT

In einer eMail vom 16.04.2008 00:10:50 Westeuropäische Normalzeit schreibt  
[email-masked]:

>> address that the packet starts out  with, and all subsequent choices

I agree with Brian: the orginating host chooses (the source address and)  the 
destination address and the respective first best hop. All subsequent  
routers are supposed to comply with.
How does the ingress router make this choice, how does it select the right  
ETR? 
I take for granted that the destination user is not supposed at all to  
influence this choice.
So I can imagine,a good choice for the ingress router  might be that  
particular ETR, which is closest.
(note : for some other ingress router, some other particular ETR will be  
closest)
But does the ingress router know which ETR is closest ? Does it even  know 
which one it should compare in order to find out the closest? If yes, isn't  it 
a big burden to do so? Or are these potential ETRs mutually like ships  in the 
night?
 
Heiner

---

From: Christian Vogt <[email-masked]>
Date: Fri, 18 Apr 2008 11:45:41 +0300

Brian,

the tussle of who should select the receiving edge network's ingress
link is not limited to host-based solutions.  It also exists in
network-based ones.  In fact, I primarily had network-based solutions in
mind when writing my email.  But I was unclear because I wrote "sender"
rather than "sending edge network".  Apologies.

Still, your related question of why there is reluctance to give hosts
topological knowledge is a related and very interesting one.  My believe
is that there is no reluctance to let hosts /know/; it is rather a
reluctance to let hosts /control/.  Because if we give hosts multiple
topologically-significant addresses to choose from, at the same time we
give them control over selecting (a portion of) the path.

Edge network operators don't want to give away control over path
selection.  This is the old issue with Shim6, which Six/One avoids
through its address rewriting capabilities.

But whether host-based or network-based path selection, it is widely
accepted that the egress link of a sending edge network should be
selected by the "sending side".  However, it is not so clear who should
select the ingress link at the receiving edge network.  I don't think
this question has ever been answered in due manner...

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 18 Apr 2008 12:05:18 +0300

Hannu,

you are too far ahead. :-)  I was still thinking on the incentives/
economic level.  Whether we decide that an ingress link should be
selected by the receiving side or by the sending side, I am sure we will
eventually find a good technique for it.  But let's first decide which
approach would be preferable.  (Feedback from the receiving side, as you
mention, will certainly be necessary if we decide that the receiving
side should select its ingress links.)

But you seem to be in favor of letting the receiving side select.  Is
this right?  And if yes, please elaborate what makes you think so.

- Christian

---

From: <[email-masked]>
Date: Fri, 18 Apr 2008 10:07:54 +0100

> But whether host-based or network-based path selection, it is 
> widely accepted that the egress link of a sending edge 
> network should be selected by the "sending side".  However, 
> it is not so clear who should select the ingress link at the 
> receiving edge network.  I don't think this question has ever 
> been answered in due manner...
> 
> - Christian
> 
> 

Set me thinking. In some way whoever pays for the link should be able to
control what happens over it, which in many cases will mean the
receiving network?

---

From: Christian Vogt <[email-masked]>
Date: Fri, 18 Apr 2008 17:02:07 +0300

> control what happens over it, which in many cases will mean the

Louise,

the receiving edge network may actually be affected by the choice of its
ingress link in close to all cases.  In some cases, though, it might in
addition have an impact on the sending edge network, because a
particular ingress link at the receiving side may force the sending side
to use a particular egress link, and this may have cost effects on the
sending side (consider peering relationships).

Conceptually, though, by giving control to those who pay, we would
certainly be on the right track.

- Christian

---

From: <[email-masked]>
Date: Sun, 20 Apr 2008 12:09:46 +0300

Christian

Incentive wise the one who carries the cost of the use of a resource
should have the choice of setting the policies and control the usage.
Receiving side knows better the local conditions of the CPE network
behind it than the remote end. The remote, or sending side, doesn't have
much visibility to the local link states and the capabilities or load
situation of the CE equipment. And I think that such details should be
abstracted away from the sending side. It should suffice, that the
receiving side announces its reachability and preferences between its
multiple egress points if such existed. 

Regards Hannu     

>From: ext Christian Vogt [mailto:[email-masked]] 
>Sent: Friday, April 18, 2008 12:05
>To: Flinck Hannu (NSN - FI/Espoo)
>Cc: [email-masked]
>you are too far ahead. :-)  I was still thinking on the 
>incentives/ economic level.  Whether we decide that an ingress 
>link should be selected by the receiving side or by the 
>sending side, I am sure we will eventually find a good 
>technique for it.  But let's first decide which approach would 
>be preferable.  (Feedback from the receiving side, as you 
>mention, will certainly be necessary if we decide that the 
>receiving side should select its ingress links.)
>
>But you seem to be in favor of letting the receiving side 
>select.  Is this right?  And if yes, please elaborate what 
>makes you think so.
>
>- Christian
>
>
>
>to require 
>> fresh reachability information for a receiving edge? Doesn't this 
>> imply that the receiving edge indicates the need somehow?
>> 
>> ingress and egress and mapping system is needed to accomplish 
>> something that is already working through BGP.
>> 
>> end point (in an managed way, not due to a failure), they 
>will signal 
>> to their intention to the other end and let the remote side 
>know what 
>> would be the "next" tunnel end point.
>>

---

From: <[email-masked]>
Date: Sun, 20 Apr 2008 12:22:04 +0300

Christian

 Talking conceptually, isn't it so that the receiving side announces its
reachablity, and if the reachability is too costly for the sender than
the sender should defer from sending, rather than contradicting how the
receiving party wants to be reachable? Again, how could the sending side
know better the local conditions that the receiving side? Each party
should have control of their own ends of the "link" or "tunnel".

Regards Hannu

>Sent: Friday, April 18, 2008 17:02
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>> Set me thinking. In some way whoever pays for the link 
>should be able 
>> to control what happens over it, which in many cases will mean the 
>> receiving network?
>
>Louise,
>
>the receiving edge network may actually be affected by the 
>choice of its ingress link in close to all cases.  In some 
>cases, though, it might in addition have an impact on the 
>sending edge network, because a particular ingress link at the 
>receiving side may force the sending side to use a particular 
>egress link, and this may have cost effects on the sending 
>side (consider peering relationships).
>
>Conceptually, though, by giving control to those who pay, we 
>would certainly be on the right track.
>
>- Christian
>
>
>
>
>--

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Apr 2008 16:30:52 +1200

> certainly be on the right track.

I don't know how to make it work though. Who pays is a very fuzzy
notion. When I access a server that sends me an unsolicited
ad, who is actually the principal payer for the traffic on my
ingress link? I think we're going to have difficulty extracting
an architectural requirement from this.

    Brian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 25 Apr 2008 12:38:17 +0300

> an architectural requirement from this.

Good point, determining the one who pays may not always be easy or
possible.  But I think in the particular case of routing at the
Internet edge, things are clearer than possibly elsewhere (especially
compared to Internet core routing; and most especially compared to
the case where you consider data content, i.e., your example).

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 25 Apr 2008 12:41:17 +0300

Thanks, everybody, for sharing your thoughts in this exercise.
The discussion has certainly shed some light on the preferred
approach of the research group in things routing control.  Here
is my conclusion:

Solutions should preferably and by default give control over a
particular resource to those entities who pay for that resource.
In the specific case of ingress link selection, this means that
the receiving edge network should be able to choose.

Solutions may go beyond this and provide a means for entities to
cede (part of) their control.  Continuing the example of ingress
link selection, a receiving edge network may announce a selection
of alternatives from which sending edge networks can choose.

- Christian

---

From: [email-masked]
Date: Sat, 26 Apr 2008 11:59:48 EDT

I think, this is a pretty challenging topic for any routing architecture  and 
not implicitly solved by any one.
Constraint: It should not multiply the worldwide routing churn. Particular  
not at those far remote regions where still  the same path were  taken.
Also, the destination host is not the only one who has a service contract  
with someone else. ISPs, mutually, too.In principle the very first hop may have  
to be compliant with the very last hop like all other in between too. 
 
As I have expressed myself several times, proper done hierachical  routing is 
THE way to match any scalability problem. And yes, the  hierarchically zoom 
could even be extended as to conceive hosts even as nodes  and therefore can do 
whichever TE routing using different last hops to the host  via different 
ISPs.
 
As a side effect the host address, though assigned by one particular  ISP, 
may as well be used by some other ISP just as if it were a PI  address.
 
Heiner

 
In einer eMail vom 25.04.2008 11:41:54 Westeuropäische Normalzeit schreibt  
[email-masked]:

- Christian

---

From: Randall Atkinson <[email-masked]>
Date: Sat, 26 Apr 2008 10:50:27 -0700

I doubt that any one party can (or should) control the inter-domain path
that a packet takes from some source site to some destination site
through some non-trivial series of ASs.

What makes more sense, to me at least, is that the party forwarding
the packet at a given moment makes its forwarding decision based
on its local policy and the information available to it (RIB, FIB, packet
header, and whatever else).  That said, clearly it is reasonable for a
destination to indicate a preferred ingress path (or a set of preferences
for ingress) to the source.  The source node then takes that information
and applies its own local policy when creating and forwarding the packet
initially.  Routers along the path might usually be in several different domains,
each with slightly different sets of reachabilities and policies.  Provided
the packet arrives, and we have some means of minimising issues
with routing loops, that is sufficient.

After all, the Internet is an unreliable datagram service.  It is NOT
a circuit and we ought not be trying to transform it into a circuit
network.  Circuit network technologies exist and folks are free to
use those if they wish, but that is not the goal of the Internet.

Yours,

Ran