architecture draft - part 1

[Tony Li <[e-mail]>]

Martha,

You write:

   A policy gateway need not understand the syntax and semantics of a
   transit policy in order to distribute a link state message.  Rather,
   the policy gateway only needs to understand the syntax of the control
   portion of the link state message (which does not include the
   policies) in order to distribute a link state message.

   Yes, to use a given transit policy to generate a route, a route server
   needs to know its syntax and semantics.  However, a route server does
   not need to understand a transit policy in order to accept a link
   state message and store it in its database.

   When new policy choices are added to IDPR, the capability to
   understand them will not be installed simultaneously in all route
   servers.  The route servers that do not understand a new transit
   policy cannot use that transit policy to make a route selection.
   However, they can store the transit policy in their routing
   information database and expect to use it later when they have the
   knowledge to interpret it.  A route server may either exclude a domain
   X with unknown transit policies from its route, or it may include X in
   its route.  That is up to the route server.  In either case, the
   policy gateways in X ultimately decide whether to accept or reject the
   path during path setup.  This flexibility allows one to gradually
   phase in new transit policies without disrupting IDPR routing.

Let me see if I understand this by giving a concrete example.  Let us
suppose that IDPR is deployed ubiquitously throughout the Internet.
In a flash of brilliance, the IETF discovers that it needs policy type
AAA to be included in a new version IDPR.  IDPR 2 is first deployed
on NSFnet.  Now, as a stub, I get a policy that I don't understand.  I
can ignore it and not use NSFnet, or I can attempt to use it.

If I attempt to use it, I may get rejected during path setup.  How
does the route server learn a new route?  What prevents the route
server from continuing to attempt to use the incorrect path?

If a route server has the ability to recover from rejected path setup
attempts, then why bother distributing policy information at all?
From some topological map, simply select a path.  If setup fails, try
a different one.  Iterate until you find something that works and then
cache it.  

If my route server does not use the route, I am effectively
disconnected.  This does not appear to be a reasonable option.

Tony