architecture draft - part 1

[Tony Li <[e-mail]>]

Noel,

   Why do we have to support deployment of new attributes? I can't
   make a concrete case, but I am willing to be a Lotus that in 5
   years we will see clearly that including this kind of flexibilty
   was absolutely necessary.

No bet.  In fact, I would wager that 5 years is much too long.  How
about 2?  No, not a Lotus, that's too rich for my blood.  ;-)

   In a minor (?) terminology issue, I would not consider that adding
   a transit policy AAA would create a 'new version IDPR' any more
   than creating a new TELNET option creates a 'new version TELNET'.
   That's the whole point of options like new transit policies. You
   can except to have interoperation with old implementations within a
   constant framework.

Please explain to me how to do this.  I see no version number in the
policy packet.  

   However, the spec should define reasonable behaviour when new
   attributes are see. I would suggest that a reasonable default
   algorithm is as follows.  First consider only the subset of the map
   which includes only link and nodes with attributes all of which you
   understand. Then, try and create a route from the source to the
   destination which meets the requested type of service constraints.
   If one is found, fine, you are done. If you fail, however, you have
   two options. You can relax the constraints and trry again, or you
   can try including links with attributes you do not understand and
   try doing a setupo to see if you succeed. If whichever one you
   tried first fails, you can try the other.

My point is that the type of algorithm is nowhere in the document
(that I can find).  I would love to be proven wrong.  I think that it
is sufficiently important for implementors to do this correctly that
it should hit you over the head when you read it.

       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.

   Tony, one of the goals of IDPR (perhaps not a popular goal at the
   moment, since people right now seem to be happy if they get they
   traffic through at all, let alone by a 'good' route, but I predict
   it will become more popular once the tools to do it are once again
   available) was to find 'good' paths to a destination, not just any
   path.

Noel, obviously I was not attempting to give an optimal algorithm.
Nor a complete one.  To be less subtle, one of the basic assumptions
about IDPR is that the policy database is consistent when it is
searched.  If you can have uninterpretable policies in it, then you
must be prepared for it to be inconsistent.  If you are prepared for
it to be inconsistent, then there are many other features that could
easily be supported (e.g., load based policy) and many of the current
problems (e.g, frequency of policy distribution) become much easier.
If recovery is a possibility, then several things need to be
re-thought.

Tony