"optimal" routes and IDPR

msteenst@bbn.com Thu, 14 May 1992 23:07 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04357; 14 May 92 19:07 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa11657; 14 May 92 19:13 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa11650; 14 May 92 19:13 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa03762; 14 May 92 18:57 EDT
Received: from ALEXANDER.BBN.COM by PARK-STREET.BBN.COM id aa03758; 14 May 92 18:54 EDT
To: B.Kumar@cs.ucl.ac.uk
cc: idpr-wg@bbn.com
Subject: "optimal" routes and IDPR
Date: Thu, 14 May 92 18:45:15 -0400
From: msteenst@bbn.com
Message-ID: <9205141913.aa11650@NRI.Reston.VA.US>

I don't believe that the architecture document ever stated that IDPR
CANNOT generate "optimal" routes.  IDPR can generate any kind of
routes that are expressible in terms of the source and transit
policies.  The point is, the route generation and selection procedures
within a domain can be as fancy or as basic as the administrator of
that domain wishes.

Remember that the route servers for a given domain are under the
control of the adminstrator for that domain.  The domain administrator
can choose how to implement the route generation procedures and the
routing information database retention procedures for its own domain.

For example, the administrator for domain X can choose to implement
its route server so that it records all routing information for all
domains and always optimizes its chosen route according to the quality
of service requested for the flow (minimum delay, minimum cost, or
maximum bandwidth).  The administrator for domain Y may implement its
route server so that it stores only routing information from domains
that do not charge for transit service and always selects the first
(not necessarily the "best") route found to a given destination.

The degree of complexity of route generation is entirely the choice
of the administrator of an individual domain.

m