unrecognized transit policies

[Tony Li <[e-mail]>]

Hi Martha,

   (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.

Thank you, I have found it and re-read it.  It does not seem to
address my concern.  It does discuss the case where the values within
the policy term are unrecognized.  Somehow the route server is supposed to
go get new information.  It does not address the case where the syntax of
the policy term has changed.

   (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 of the time that the RFC was written...

   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.  

And I agree.  But there seems to be no way to migrate forward.  If the
structure of the policy term changes, the protocol seems to stop working.

And are we experimenting with IDPR, or just deploying it?  I will note my
continuing dissent here, and move on.

   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.

The path agent should also feed the failure information back to the route
server so that the route server does not continue to generate bad routes.
The path agent should also flush its cache of all inactive paths including
X.

In short, the originator must be prepared for the path setup to fail.

   (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.

From the above, we have stipulated that the path database at the originator
is not absolutely accurate.  It does provide data which the route server
may use in calculating a route to be attempted.  It is not necessary that
the routing information be completely up to date.  Since one of the
significant overheads in this protocol is the rapid and reliable
distribution of this routing information, it would make sense here to
reconsider the tradeoffs.  If route distribution is less rapid, then
overhead is decreased, especially for those destinations which are not in
use.  For the destinations that are in use, an error in path setup would
indicate that the current routing information about the domain in which the
setup error occured was not up to date.  If this could be refreshed on
demand at this point, the route server would not need to be rapidly
updated. 

   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.

While I agree that it is expensive, I also think that full, rapid
flooding of policy information is expensive and that a tradeoff here
between the two is possible and beneficial.

Tony