Brijesh's comments on route selection

[Martha Steenstrup <[e-mail]>]

Hello Brijesh,

In addition to my responses, I have included some of your comments for
context.  Each of your included comments is preceded by a ">>".

>> 1) How will AD X send the identity of chosen virtual gateways to AD A
>> and AD B? I thought IDPR route setup packet lists only transit ADs, not
>> the individual virtual gateways in the route. Am I wrong here?

Yes, you are mistaken.  With IDPR, routing information messages
contain information about the virtual gateways associated with an
administrative domain and about the transit policies that apply on the
intra-domain routes connecting these virtual gateways.  Hence, a route
server has sufficient information to distinguish among virtual gateway
entry and exit points for a given IDPR domain and takes this
information into account when generating and selecting policy routes.
Each IDPR route is specified as an alternating sequence of virtual
gateways and administrative domains contained in the route.  This IDPR
route representation is used both in the policy route database and in
the path setup message used to establish the route across the
constituent domains.

>> 2) Are n't you assuming a particular cost model above by using monetary
>> cost as an example?

In the example I gave, the "cost" was not restricted to being a
monetary cost.  It could be, for example, a delay-related cost.  The
only restriction was that the cost had to be proportional to distance,
in order to fit with the assumptions of the Motonori problem.

>> In this situation, monetary costs of above links (between AD A and AD B
>> or links between B and Y) have no relevance to AD X (otherwise I will be
>> bothering about the cost of 200 or more inter-domain links whose existence 
>> I may not even be aware of for sending this particular message :-).).

With IDPR, we wanted to give each transit domain the ability to
specify the monetary cost of using each of its resources and the
source domain the ability to select routes based upon the expected
monetary cost incurred when using a given route.  This does not mean
that all domains have to advertise costs or account for them in route
selection.  Contrary to what you suggest, a route server in a source
domain will be aware of each domain from which it receives a routing
information message.  Hence, the route server will also be aware of
each virtual gateway (i.e. inter-domain link) associated with that
domain.

>> Secondly, realistic monetary costs is not easily expressed as a single 
>> comparable parameter as we may think. It is difficult because there are 
>> infinite ways in which charging policies can be made for a link usage. 
>> Therefore, using monetray cost, IMHO, is probably not the right idea.

You are correct in saying that monetary costs are difficult to deal
with.  A domain administrator may decide to charge, for example, for
each packet carried, for amount of time its resources are used (as do
the long-distance phone carriers), or a flat monthly charge allowing
unlimited use (as do the RBOCs for local calls).  Currently, in IDPR
monetary cost can be specified as a per packet, per byte, or per
session time charge.  We expect to modify and refine the flexibility
of advertising a domain's monetary cost for service, as administrators
figure out whether and how their domains will charge for service.  For
now, IDPR has some limited ability to express and act on these
monetary costs.  However, I disagree with you that monetary cost is
"not the right idea".  Some domains are going to charge for service,
and some users are going to want the cheapest routes.  Routing
protocols should deal with this.

>> If advertised policies are modified by talking on phones, will that not
>> create internetwide inconsistencies of policy database amongst ADs? Imagine
>> if such modified database is passed from one AD to another. Where will buck
>> stop? 

In IDPR, there is no entity called a "policy database".  Perhaps you
are equating "policy database" with "routing information database"?
I'll assume that this is the case and proceed.

With IDPR, the routing information databases maintained throughout the
an internetwork may not be consistent.  This is independent of whether
or not there exist policies learned over the phone.  Each domain can
decide which of the received valid routing information messages to
store.  Thus, the routing information databases are not necessarily
consistent across an internetwork.  With source-specified routing, we
don't have to worry about looping problems associated with
inconsistent routing information and hop-by-routing.

Now baxk to "over the phone" policy distribution.  Transit policies
learned "over the phone" would most likely not be in the format of
IDPR routing information messages, complete with source signatures,
timestamps, and such.  If they were in this format, then it would make
more sense to distribute them via IDPR than over the phone.

Over-the-phone policy distribution is outside the scope of IDPR.
Hence, such policies would not be incorporated into the IDPR routing
information database.  Instead, they would be placed in a special
database containing such information learned through mechanisms
outside of IDPR.  It is up to a source domain that wishes to obtain
and use this type of policy information to decide how to do it; it is
not the responsibility of IDPR to deal with this information.

The policy information in the special database would not be
redistributed by the IDPR routing information distribution procedure,
because it would not in the IDPR routing information database and
because it would not be in the format required for routing information
messages.  One could design a protocol for distributing this policy
information among domains, but that would be external to IDPR.

If I have misinterpreted your question, please let me know.

m