Re: an enquiry

B.Kumar@cs.ucl.ac.uk Wed, 25 November 1992 13:07 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02664; 25 Nov 92 8:07 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02660; 25 Nov 92 8:07 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa07290; 25 Nov 92 8:08 EST
Received: from pizza by PIZZA.BBN.COM id aa18941; 25 Nov 92 8:03 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa18937; 25 Nov 92 8:01 EST
Received: from bells.cs.ucl.ac.uk by BBN.COM id aa21434; 25 Nov 92 8:01 EST
Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.11446-0@bells.cs.ucl.ac.uk>; Wed, 25 Nov 1992 13:00:36 +0000
To: Yuko Murayama in Tokyo <murayama@nc.u-tokyo.ac.jp>
cc: idpr-wg@bbn.com, motonori@kuis.kyoto-u.ac.jp, sone@hitachi-cable.co.jp, murayama@angora.nc.u-tokyo.ac.jp
Subject: Re: an enquiry
In-reply-to: Your message of "Wed, 25 Nov 92 17:29:36 +0900." <9211250829.AA23845@angora.nc.u-tokyo.ac.jp>
Date: Wed, 25 Nov 1992 13:00:30 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: B.Kumar@cs.ucl.ac.uk
Message-ID: <9211250808.aa07290@CNRI.Reston.VA.US>

Yuko Murayama writes:

>We have a working group of policy routing at WIDE Project, Japan, 
>starting studying IDPR.
>
>We have a small policy-routing problem which is termed 
>"the Motonori Problem," because it was first defined 
>clearly by Motonori Nakamura at Kyoto University.
>
>The problem is: how can one enforce the preference of transits?
>Suppose that we have two transit ADs, A and B between the source AD X
>and the destination AD Y.  There are more than one interface (VG)
>between A and B as follows:
>
>
>Y1                    AS Y (destination)
>|                  
>---------------------
>|                   |
>|       AS B        |
>|                   |
>---B1----B2----B3----
>   |     |     |
>   |L1   |L2   |L3
>   |     |     |
>---A1----A2----A3----  
>|                   |
>|       AS A        |
>|                   |
>---------------------
>                  |
>                  X1  AS X (source)    
>
>When one at AD X wants to send a message to someone at AD Y,
>how can one say, "packets should go through AD A as much as possible,
>and pass through B as less as possible due to some cost parameter" ?

I donot get it. If A and B are the two ADs between X and Y, any packet that
is passing through A will also pass through B. This assumes that there is no
other path for A to send packets to Y. If you have more paths, then one set
of traffic can go on route (X,A. (AD other than B).Y) and second type of
traffic can go on route (X,A,B,Y). This would require QoS support in forwarding
to differentiate between two types of traffics. Routers have no mechanism to 
define meaning of term "as much as possible.". Someone has to provide a 
forwarding "hint" to routers (or to route server in case of IDPR). This is 
implementable both with IDPR and BGP/IDRP.

>Does a local route server at X have knowledge on locations of VGs, L1, L2, 
>and L3, so that pakcets from X to Y would take L1?

I am not sure whether IDPR implements it or not. But it is not difficult
to make such "bilateral arrangements" with  AD A and AD B. For example, 
A can always set a flow through link L1 whenever it gets a flow setup request
from AD X. This is for the case of a route setup protocol like IDPR. 
For BGP/IDRP, pl see next paragraph.

>
>Using BGP one could implement this policy to some extent, but not exactly
>because, if my memory is correct, B has to
>advertise each interface with different preference for the sake of A/X...which
>is not necessarily B's own policy.

Actually, this can also be done in BGP and IDRP like protocol using three
different QoS types for the traffic. See use of MULTI-EXIT_DISC attribute in
IDRP for using one of the multiple links in the neighbouring AD. Therefore,
one type of traffic from X can go on link L1, second type of traffic on link
L2 and third type of traffic can go link L3. 

In other words, simple problem with IDRP/BGP is that a FIB entry cannot have
multiple next hop gateways for the same destination. Hence A, cannot have
L1,L2 and L3 all listed in one FIB entry for destinations in Y and choose
using a policy like "use link L1 as much as possible". There is no option but
to define multiple FIBs even if they are set sepeacilly for servicing a
single neighbouring AD.

This is all theory as QoS forwarding is not implemented in most gateways.
However, I believe that implementing this locally is not difficult.

Cheers,

brijesh

Department of Computer Science 
University College London 
London WC1E 6BT(U.K )