Re: routing by preference

村山優子 <murayama@theta.iis.u-tokyo.ac.jp> Mon, 15 November 1993 09:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29333; 15 Nov 93 4:46 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29329; 15 Nov 93 4:46 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa02484; 15 Nov 93 4:46 EST
Received: from pizza by PIZZA.BBN.COM id aa24554; 15 Nov 93 4:41 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa24547; 15 Nov 93 4:39 EST
Received: from theta.iis.u-tokyo.ac.jp by BBN.COM id aa22240; 15 Nov 93 4:39 EST
Received: by theta.iis.u-tokyo.ac.jp (5.64/6.4J.6) id AA08372; Mon, 15 Nov 93 18:38:40 JST
Return-Path: <murayama@theta.iis.u-tokyo.ac.jp>
Message-Id: <9311150938.AA08372@theta.iis.u-tokyo.ac.jp>
To: Martha Steenstrup <msteenst@bbn.com>
Cc: idpr-wg@bbn.com
Subject: Re: routing by preference
In-Reply-To: Your message of "Sun, 14 Nov 1993 18:19:17 EST." <9311142342.AA09739@sh.wide.ad.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Date: Mon, 15 Nov 1993 18:38:38 JST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: =?ISO-2022-JP?B?GyRCQjw7M00lO1IbKEI=?= <murayama@theta.iis.u-tokyo.ac.jp>

Martha,

Thank you for your valuable comments and suggestions.

Here are my views.

> I think you have to be careful when deciding when you actually want to
> route by preference.  With strict routing by preference, the local
> optimizations in unfavorable domains do not necessarily lead to
> end-to-end optimization between source and destination domains.
> Hence, you must decide when the shortest end-to-end path takes
> precedence over selecting the shortest routes through unfavorable
> domains.  Moreover, if the source requires that the qualities of
> service and the monetary cost of service for a route be kept within
> specified constraints, then satisfaction of these constraints should
> take precedence over selecting the shortest routes through unfavorable
> domains.

This is the good point.   In routing by preference, originally 
we do not care too much about what it would cost in favourable parts.
That is, the total cost may not be optimized. We want to minimize 
the costs only in the particular parts --- i.e. unfavourable domains,
in the first plase.

However, if it does not fit well with the realistic routing scheme 
of the Internet, then we can modify it as "routing by *weak* preference" 
instead, so that a preference route can be selected only if it is 
within the source constraints.

(By the way, would there be any "destination" constraint?)

> You could include as part of the source policies, the preferences of
> the destinations listed in the source policy.  For example, if
> destination Hz considers that domain W should be avoided if possible,
> this information will be incorporated into the source policies
> involving destination Hz.  Hence, these sorts of destination
> preferences could be accommodated without modifying IDPR.

I understand that the destination's preference is dealt with easily
by incorporating it into the source policy database in each possible 
source domain. 
However, I still wonder if it is not feasible to distibute the 
destination's preference as a part of domain routing information. 

> You also mentioned the ability to factor in the "cost" in travelling
> from source or destination hosts to virtual gateways in the same
> domains in order to choose a favored exit virtual gateway from the
> source domain or entry virtual gateway at the destination domain.
> .....
>
> Nevertheless, for a single source host you could do the following.  At
> the source domain, if a host were configured with information about
> its favorite exit virtual gateway, it could loose source route all of
> its inter-domain traffic to this favorite virtual gateway.  The
> virtual gateway in trun would select an IDPR policy route to the
> destination.  However, this implies that the host also knows which of
> its traffic is intra-domain and which is inter-domain.  Perhaps the
> first-hop router for the host could make this determination and could
> force loose source routing to the preferred virtual gateway, on behalf
> of the host.

This first-hop could be the first IDPR router. That is, the first hop
would not be the optimized exit. Then, if there is any other appropriate
exit, this first hop can forward the packets to this exit router,
informing the inra-domain router of the better exit IDPR router as
the first hop --- identical to the way the ICMP Redirect works.

Thank you again for the informative suggestions.

Yuko