Brijesh's comments on route selection
Martha Steenstrup <msteenst@bbn.com> Mon, 30 November 1992 19:30 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13500; 30 Nov 92 14:30 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13496; 30 Nov 92 14:30 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa11056; 30 Nov 92 14:31 EST
Received: from pizza by PIZZA.BBN.COM id aa02332; 30 Nov 92 13:23 EST
To: b.kumar@cs.ucl.ac.uk
cc: motonori@kuis.kyoto-u.ac.jp, sone@hitachi-cable.co.jp, idpr-wg@bbn.com
Subject: Brijesh's comments on route selection
Date: Mon, 30 Nov 1992 14:19:50 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Martha Steenstrup <msteenst@bbn.com>
Message-ID: <9211301431.aa11056@CNRI.Reston.VA.US>
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
- Brijesh's comments on route selection Martha Steenstrup
- Brijesh's comments on route selection Martha Steenstrup