Subject: RE: Next question...

From: "Tony Li" <[email-masked]>
Date: Sun, 8 Dec 2002 02:16:08 -0800

Tony,

|   > My concern is not so much about loss of control as it is with 
|   > the administrative burden of implementing the policies.  
|   
|   Isn't perception of burden really a function of direct vs. indirect
|   control? 

Umm... no, it's a function of the number of unique operations necessary
to implement and maintain the desired policies.

|   > Most policies are going to be site-wide, not host specific.  
|   > Having to distribute this policy and keep it consistent 
|   > across an enterprise can be done by our standard system 
|   > administration tools, but the effort involved in doing so is 
|   > non-trivial and the number of exception hosts is likely to be 
|   > small, so this just seems like a poor ROI for the site 
|   > administrator(s).
|   
|   I agree that most policies are site wide, but ROI depends on how
|   valuable the exception list is. If you are in the exception 
|   list, your
|   perspective is different than if you are not. As far as 
|   triviality, that
|   depends on the mechansim. If it were something like a 
|   static policy on
|   all host to prefer the prefix order in the RA, it seems 
|   pretty trivial
|   to me.

Such a policy is trivial regardless of the location of policy implementation.
The question is about the effort to distribute that policy.  If it's
on the SBR's then it's less than ten systems.  If it's on the hosts,
then it's thousands and any rogue sysadmin can abuse it.

|   > Our job, as architects, is not to create an architecture with 
|   > infinite flexibility.  Rather, it is to reject those options 
|   > which lead to unnecessary complications down the line.  
|   
|   And our disagreement really comes down to definition of 
|   'necessary'. 

True.  Why is individual host control 'necessary'?

|   > Control at the host seems like an infrequently used feature.  
|   
|   Frequency is not an indication of value. Besides it is done on every
|   connection today, so that seems pretty frequent to me. 

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

|   > Note that policy for a specific host can be implemented 
|   at either the 
|   > site border router (SBR) or at the host, so removing the 
|   > policy decision from the host isn't actually eliminating 
|   > architectural flexibility.
|   
|   I absolutely disagree. Hosts actually make those policy 
|   decisions today,
|   and the system works. The machine I am typing this on has 4 IPv4
|   addresses, yet it has no trouble opening a connection to CNN.com by
|   picking from that list of possible sources, and the 8 available IPv4
|   destination addresses. There seems to be a fear that providing more
|   choices to the host will magically make the world more complex. 

No.  Providing the host with the information so that it can make the
choice about 8 destination addresses and 4 source addresses is part
of what's scary.  That and distributing the policies.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 9 Dec 2002 14:15:38 -0800

Tony Li wrote:
> ...

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

---

From: "Craig A. Huegen" <[email-masked]>
Date: Mon, 9 Dec 2002 17:22:19 -0600 (Central Standard Time)

Tony,

> so moving this function to the routing system is not an engineering

Depending upon what your belief is of the current best common practice for
multi-homing, one could argue hosts in IPv4 actually do the identifier
selection and the routers select the path which is analagous to the
concept of a locator.  This is in the case of PI space -- we take this
approach with the multi-homing of Cisco's network, to the extent that
www.cisco.com has a single A record and the routing system has the true
"locators" (in the form of BGP paths).

> so we will end up choosing the winner/looser.

It is certainly not this.  I would love to be able to hand a policy
specification to my counterparts in our desktop standards group and have
them figure out how to apply this, in communication, coordination, etc.
Less work for my team.  But I recognize (as detailed in a previous e-mail)
that the time and effort required to manage the configurations on a
significant number of hosts and various permutations of host
capabilities/extensions is far greater than an extensible policy
infrastructure that allows me as the administrator to change policy and
immediately have it applied across the entire infrastructure.  I can
enhance the policy engine on less than 30 devices globally as opposed to
coordinating features from a number of vendors for a number of operating
systems for 100,000 hosts.

/cah

---
Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
IT Transport, Network Technology & Design           ||        ||
Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
San Jose, CA  95134, (408) 526-8104                ||||      ||||
email: [email-masked]       CCIE #2100      ..:||||||:..:||||||:..