Re: a question on policy gateways

[Danny Lee <[e-mail]>]

The routing objectives that you mentioned in your email note are
supported in the present design of IDPR via source policy
specifications.  Source policies allow the originating domain to
specify which domains to { "exclude", "avoid", or "favor" } when
computing a route.  As indicated in the IDPR specification, the
{ exclude } attribute will yield routes that exclude the domain to
which the attribute is tagged.  The { avoid } route is interpreted
as a routing bias, with the possibility that a route may traverse
the indicated domain.

We have implemented routing by preference in our version of the IDPR
code for GATED in the following way.  The { avoid, favor } attributes
map into a routing metric that is used during graph search.  (Domains
that do no have the { avoid, favor } attributes map to a default value.)
The { exclude } attribute is used prune the graph that during graph
search.  To ensure that certain routing algorithms (e.g., Dijkstra's
SPF) do not cycle till negative infinity, the { avoid, default, favor }
attributes map into positive values.

> How about W1 and S3/S4?
> Should W1 be able to monitor the connectivity 
> between S1 and S3/S4?

One possible perspective is to view transit policies as a set of
intradomain virtual links that is available to carry interdomain
traffic.  Thus, receipt of a transit policies by W1 from S1 that
reference S3 and S4 in virtual gateways can be construed as the
existence of connectivity between the set of gateways { S1, S3, S4 }.
By intelligent updating and interpretations of transit policies,
remote domains can derive a fairly complete description the entry
and exit points (i.e., interexchange points) within the internetwork.

Danny.