routing by preference

Martha Steenstrup <> Fri, 15 October 1993 16:04 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa08215; 15 Oct 93 12:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08211; 15 Oct 93 12:04 EDT
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa23242; 15 Oct 93 12:04 EDT
Received: by PIZZA.BBN.COM id aa15687; 15 Oct 93 12:02 EDT
Received: from pizza by PIZZA.BBN.COM id aa15411; 15 Oct 93 11:19 EDT
Received: from KARIBA.BBN.COM by PIZZA.BBN.COM id aa15407; 15 Oct 93 11:16 EDT
Subject: routing by preference
Date: Fri, 15 Oct 93 11:18:42 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Martha Steenstrup <>
Message-ID: <9310151204.aa23242@CNRI.Reston.VA.US>

Hello Yuko,

Video tape presentation at IETF is indeed a possibility.  I will check
on the availability of VCRs and monitors.  However, as you won't be
present at IETF to answer questions that may arise from your video, I
encourage you to post to this list, prior to IETF, any papers that you
may have available on your work.  That way, people can gain a better
understanding of your work and you can start a discussion going before
people view the video.

You say:
"If there were multiple virtual links between ADs, 
 cost information of *inra-AD* paths would be required 
 to decide *inter-AD* paths in terms of policy gateways."

When you say multiple virtual links between domains do you means
multiple virtual gateways between domains or multiple virtual links
across a given domain between virtual gateways?

IDPR permits specification of multiple transit policies between a pair
of virtual gateways attached to a domain.  There may be multiple
intra-domain routes between policy gateway members of these virtual
gateways, each with different "costs" (i.e. qualities of service and
monetary costs of service).  This "cost" information is in part what
makes up the definition of a transit policy.  Thus, intra-domain
"cost" information is a component of IDPR inter-domain routing

You say:
"However, it seems a bit awkward that inter-domain
 routing needs intra-domain information in
 hierarchical routing."

But the characteristics of a domain, such as service offerings and
restrictions, are determined by the service offerings and restrictions
of the intra-domain routes.  Hence, inter-domain routing information
must be built from intra-domain routing information.  IDPR routing
information is not concerned with the the exact intra-domain routes,
terms of the component routers and links, but it is concerned with the
characteristics of the intra-domain routes between domain entry and
exit points.

You say:
"On the other hand, I thought that we could collect intra-domain
 cost information by means of network monitoring tools, 
 if it was not provided by the distributed inter-domain 
 routing information."

But IDPR already provides intra-domain cost information in a domain's
transit policies.  Unless I've completely misunderstood your goal, I
don't think you need to obtain more detailed information about
intra-domain routes.

Recall that the IDPR path setup message contains the path in terms of
domains and virtual gateways connecting them.  It also contains, for
each domain in the router, the transit policies found to match the
source service requirements and some of the source service
requirements themselves.  Thus, during path setup, a policy gateway in
a virtual gateway at the entry of a domain selects the intra-domain
route to a policy gateway in the exit virtual gateway, according to
the transit policy listed in the path setup message and the source
service requirements.

For example, suppose there were three transit policies, A, B, and C
between two virtual gateways associated with a domain.  Suppose that
the source has selected a route based upon the compatibility of its
service requirements of low delay with the delay advertised in transit
policy C.  During path setup through the given domain, the policy
gateway receiving the path setup message would choose an intra-domain
route supporting transit policy C, in order to send traffic on that
path across the given domain.

You say:
"Yes, we expected that a part of routing by preference
 would be solved by idpr, because the source's preference
 can be treated as a source's policy in idpr.
 However, there is yet another part of the problem: 
 destination's preference."

Currently, IDPR does not permit a destination to exercise a preference
in route selection.  During path setup, it may refuse to accept a
route because of its access restrictons, but it plays no part in
selection of a route based on "costs".