Re: architecture draft - part 1

[Noel Chiappa <[e-mail]>]

	Tony:

	You are making a very important point. Adding a new attribute (i.e.
transit policy) to the set which can be applied to map elements should be
something we expect to happen, and cases such as the one you mention should
not cause near-global disruption/failure of the routing. The system simply
*must* do something reasonable in this sort of circumstance.
	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. We aren't smart enought to forsee *every* future need, but we
*are* smart enough to provide a system that will easily grow to handle them.
	(The need to support this kind of extensibility points out,
parenthetically, the absolute necessity of source routing. You can't provide
this without source routing; routing loops will result if you are using
hop-by-hop forwarding.)


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


	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.
	There are obvious variations; presumably there is a knob on the 'just
try things' option which limits how many different ones you try before giving
up. You could alternate between the two, relaxing the constraints/increasing
the value each time, until you hit some ceilings.
	 I can't say a priori which a given application or site would prefer.
There is no harm in different places making different choices. Alternatively,
a site could write its own route creating algorithm which does something
totally different. As long as it behaves *reasonably* (hard to define, I
know) in the presence of unknown attributes, you are OK. In any case, a
site which has a *unreasonable* algorithm harms only that site.
	(This is *another* advantage of source routing. You can incrementally
deploy new routing algorithms, including experimental ones, with *no* central
coordination and *no* possibilty of harm to the rest of the system.)

	Obviously, even better algorithms can be devised if we were to
divide attributes into inclusive and exclusive (i.e. the latter ones mean
that not all packets will be allowed through the link).
	

    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.
	I am aware that not every effort is taking this path at the moment,
but the algorithm you suggest would be in direct conflict with a (possibly
unstated) goal of IDPR. (RFC1126, the document when sets out the goals for
this effort, is murky about whether or not it is a goal. It does say that
maximizing resource usage is not a goal, but minimizing paths is not the
same thing..)
	I am aware that finding 'good' paths is a rather more complex
operation (attempting to do which runs you into corners in which looping is
more likely in a non-source-routed system), but it seems a very desireable
goal. RFC1126 notwithstanding, on a large scale real-world economics will
drive you to try to keep resource usage down to some degree. Exactly how close
to optimum you need to get depends on the future balance between the cost of
optimizing and the cost of the resources, something which is as yet unknown.


	Noel