RE: Next question...

["Tony Hain" <alh-ietf@tndh.net>]

Tony Li wrote:
> ...
> AFAIK, no host has the wherewithal to make the intelligent
> routing decisions that you're proposing.  Which connections are you
> thinking of?

I am not suggesting that the host make a routing decision ...

The only thing the host has knowledge of are the locators. Yes those are
the objects the routing system keys on, but the host is doing nothing
more than selecting the endpoints. The routing system actually does the
path selection job, and the host should have no direct role in that,
because they don't have sufficient information to do so. 

If the goal is service optimization and the origin end system decides
that the selected path is not acceptable for the application, it may
wish to have alternatives explored. It could request that the routing
system just do that, but then it would have to explain what
characteristics it was looking for (RSVP), and the routing system would
have to have a mechanism to measure the possible paths (???). The
alternative is that the origin end system walk through the lists of
locators to see if any result in acceptable service. It is not doing
path selection per se, but leveraging the fact that the routing system
will key off the locators to do that. This approach leaves knowledge of
the desired characteristics and measurement located close to the
application, and distributes in a way that scales much better than an
SBR. 

OTOH, if the goal is policy enforcement through locator selection, the
SBR may provide a more scaleable approach because it limits the number
of places that have to understand the policy. This could also be done by
having the network inform the end systems about the policy, but concerns
are raised about crossing an artificial trust boundary. If the focus is
on the term 'enforcement', crossing trust boundaries is a big deal and
perceived costs will always outweigh potential benefits. If the focus is
on scalable application of a policy, moving the process to the edge is a
more reasonable engineering approach. 

As I said earlier, hosts already do the locator selection today. The
routing system seems to be intact (as much as it is capable of anyway),
so moving this function to the routing system is not an engineering
decision based on scale, it is one based on perceived need for control.
It is my understanding that the need for control stems from TE
requirements where egress policy wants to enforce the destination
locator, and ingress policy wants to enforce the source locator. While
rewriting the locators at the SBR may allow a site network admin to
achieve fine-grained TE, the approach requires rebuilding the hosts and
applications to live with arbitrary external changes. The lack of
coordination between the sites also means it is not possible to
arbitrarily meet the ingress & egress policies of both sides. Given all
that, what problem are we trying to solve? 

If it is to support failover, encapsulation techniques work, and
translation would work when the applications were unaware. 

If it is TE load distribution, we need a negotiation protocol between
the sites to figure out the mutually acceptable set of locators from the
options (else we end up violating policy on one end). 

If it is performance or differing service types, we need a mechanism for
the application to declare / identify the acceptable levels of service. 

If it is for AUP, we need to know if the granularity is per host, per
application, or per user, or combinations thereof. (Per host or per
unencrypted application is possible in the SBR, but per encrypted
application, per user, or combinations would require the host to be part
of the solution space.) 

If it is all of the above (as per the multi-6 requirements draft), we
need a mechanism that can identify and track the acceptable level of
service for each application, adheres to the AUP (most commonly per user
& app simultaneously), meets the TE policies of both ends (while still
allowing any transit providers complete control), and fails over
gracefully with no more disruption to the app than the lost packets. 

If it is petty bickering about control between the host or routing
system administrators, we can't define a standard that will satisfy both
so we will end up choosing the winner/looser.

Once we sort through that list, we need to figure out where to apply it.
From my experience, the first two probably scale more cost effectively
in the SBR (though translation approaches would require changes in all
hosts and applications), while the second two scale more cost
effectively in the hosts, and the last two are hopeless. This leaves us
without a clear path, so the tendency is to gravitate to the one the
participants are most familiar with; doing it in the routing system.

My point is that by focusing on the SBR approach, we are starting from
the point of application, without really agreeing on the problem space.
While people use different aspects of the requirements list in different
situations, they can't all be used simultaneously (take the simple case
of path selection by both ends and the middle). 

Maybe rather than stating the list as requirements, claim they are
capabilities that are used in the current IPv4 environment. Then require
all architectural approaches to address how well they address each of
those capabilities, and comment on the scaling trade-off's or protocol
additions that would be required to implement that architecture.

Tony