unrecognized transit policies

[[e-mail]]

hi tony,

i have discussed this issue in response to some of yakov's questions
concerning the architecture document, so i won't rehash what i've
already said there.  however, i will respond to those of your
questions that i did not address in the earlier message.

(1) the subject of unrecognized transit policies in routing
information messages has been discussed in each version of the idpr
protocol specification.  the discussion has always been contained in a
section called "message incorporation" in the routing information
distribution section.  so you should be able to find it, even if you
have a very old version of the specification.

(2) we have tried to offer a wide variety of source and transit
policies in the initial version of idpr.  the choice of transit
policies was in large part influenced by rfc 1125, which described the
transit policies requested by government-sponsored networks.

as people begin to experiment with idpr, i expect that they will ask
for some new types of source and transit policies that are not
currently part of idpr, and we will have to add to the route servers
the ability to understand these new policies.  however, i do not
expect new policies to be added every day, or even every week.  policy
additions i expect to be infrequent events.  with the ability to store
unrecognized policies for later use and the ability to use routing
information that it does recognize from a domain advertising some
unrecognized policies, the route server should be flexible enough to
operate in an environment in which new policies may be introduced.

(3) if a route server chooses to include in a route a domain for which
it does not understand all of the transit policies and if during path
setup that domain rejects the route because of a policy inconsistency
problem, the originator path agent must attempt to find a new route.
when a path setup is unsuccessful, the policy gateway that makes this
determination returns to the originator path agent a refusal
indicating the reason for the path setup failure.  this information
helps the originator path agent select a new path.

in the case of a policy inconsistency problem at a given domain X, the
originator will attempt to select from its cache a route that does not
include X.  the path agent may have to request a new route from the
route server, and if so, it will request that domain X not be
included.

we recommend that whenever a path agent requests routes from a route
server it request more than one acceptable route, so that if path
setup fails there will be a likely candidate to back it up.  (if the
two routes are not disjoint, then it is possible that the alternate
route may fail at the same point as the original route.)

(see the sections of the protocol specification describing route
generation, path setup, and route server query, for a more detailed
discussion of the above.)

(4) you suggest not passing around any policy information and instead
letting path setup ultimately select appropriate routes.  while this
would work, i don't recommend it.  distributed policy information
allows route servers to make well-informed decisions about what routes
to select in response to requests.  moreover, the probability that the
path setup for the route will succeed is high, given that the routing
information database is kept up-to-date through rapid and reliable
distribution of routing information.

relying on path setup for route selection may result in several false
starts on path setup.  the resources associated with partially setting
up and then tearing down failed paths are unnecessarily wasted by this
process.  moreover, the route servers are going to have to supply the
path agents with many routes to increase the chances of getting an
acceptable one.  while i do expect some path failures of this sort, i
do not expect this to be the usual mode of operation.  i think it is
too expensive.

m