> In the context of the current Internet, one could say there are
> three components to policy:
> 1. Ingress policy - this controls what routes you accept from your
> neighbors.
> 2. Route selection policy - this controls how you take the routes
> you have available to use to make forwarding decisions.
> 3. Egress policy - this controls what routes you send to your neighbors.
> These three components form the flow of routing, although routes
> that are originated from the local router may start at step 2.
> At each step, the route may be manipulated to change its properties.
> These properties may be used to affect policy at a given stage,
> either in the local speaker or some remote routing entity.
> To effectively talk about policy past this abstraction, we need
> to define the properties that the route has and the "expected"
> behavior of how those properties will affect default route selection
> in a remote routing entity or make available properties by which
> they can exercise their own policy.
I think we should look at the policies from the perspective
of what ppl are trying to achieve when using them, rather
than what exact effect on the current routing system they
have.
With this in mind, the *first* *approximation* could be something
like this:
Domain entry policies:
Influence the decision of remote entities on which entry
points to the local domain are chosen for a specific set
of local destinations.
Domain exit policies:
Influence the local decision on which domain exit points
should be taken when forwarding traffic to a set of
remote destinations.
Domain transit policies:
Influence the decision of remote entities on whether/which
entry and exit points are chosen when forwarding to a set
of remote destinations through the local domain. Can be
subdivided into two subgroups:
Domain transit entry policies and
Domain transit exit policiies
From a more generic perspective, "to a set of destinations" can
actually become "to & from".
> ...
> I'm very curious how we intend to approach "policy" in the next-generation
> routing protocol. In the context of "privacy", policy is pretty
> opaque from most providers - you can only see the results of it.
What would be interesting is whether at least some part of policies
would be ok to be exposed, and to what extend exposing the policies
is a problem (i.e., finally, with enough thrust, one could probably
figure out "how guy X is treating my traffic").
> If policy is to remain opaque we are probably constraining ourselves
> to something like the current Internet where things incrementally
> converge.
Not sure about this. It depends on how the implementation of
forwarding and how the forwarding state is established.
Assume that the base system only does topology discovery,
reachability distribution, and default fwd'ing state establishment,
i.e., no policy. Also assume that we have separate policy
negotiation protocol. Now I want to "correct" path A-B so
that it fits my policy. I do preliminary calculation based
on (hopefully) announced policies and start the policy
negotiation procedure, which allows every transit entity to
check whether the fwd'ing state matches local policies or
not without having to expose all of them.
The above example definitely suffers from scalability
problems (RSVP is the keyword ;), but it is a valid example
of how policy routing can be done without exposing all
policies.
Alex.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT