Re: requirements draft revision

[Tony Li <tli@Procket.com>]

 | The real requirement is that customers be able to control, through 
 | whatever mechanism or mechanisms, the flow of traffic.  Your statement
 | above is one point in that space, but there are many others in use
 | everyday on the Internet.


Today's routing architecture provides policy control for inter-domain
traffic, but gives complete control over that policy to the source and
transit domains along the path.  Today's architecture gives NO direct,
technical control to the destination.  The way that the destination
influences transit policy is through the use of external motivation
(i.e. cash changing hands) or through the use of advisory information
injected into routing.  In this latter class, the mechanisms are simply
those that take advantage of some side effects in the normal policy
computations of the transit domains.  Specifically, by injecting a longer
prefix, their announcements take priority over aggregated announcements.
By padding the AS path, they can make one entry preferable to another.

If your real requirement is to extend the policy control of the
destination, then you must also accept the fact that there must be
distribution about the policy requests of the destination to the transit
domains.  However, distributing this information is exactly what is causing
the indigestion in the routing subsystem today.

I submit, therefore, that the real, scalable, requirement for the routing
architecture is somewhat different: that the destination domain NOT be able
to technically inject any policy information into the transit domains
whatsoever.

Policy wonks will observe that this causes the destination domain to revert
to using cash to influence transit routing policy, thereby eliminating the
tragedy of the commons that we live with today.

Regards,
Tony