RE: Next question...

["Craig A. Huegen" <chuegen@cisco.com>]

On Fri, 6 Dec 2002, Tony Hain wrote:

> 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.


Start tracing to all those addresses you get with www.cnn.com.  That is
*not* multihoming, that's local infrastructure resiliency via DNS
load-balancing.  Those prefixes are all located within Atlanta.  Take a
look in BGP route tables and see that the real path selection happens in
the routing infrastructure via BGP paths.

The fact that your host randomly picked a destination address from DNS and
used the outbound interface's primary IP address for a new connection
isn't true multihoming.

Now, take a scenario:  Your host has source addresses from aaaa::/16,
bbbb::/16, cccc::/16, and dddd::/16.  Destination host has source
addresses from aaab::/16 and dddf::/16.  You pay $100k per megabyte from
the provider allocated aaa0::/12, and $2 per megabyte from the other
three.  You also need every host in your organization to be able to use
the aaa0::/12 provider to reach a very critical service with address
aaaf::/16, which you're willing to pay the $100k per megabyte for.  This
critical service also has connectivity via providers B and D in bbbe::/16
and ddde::/16, but with sub-par connectivity and you want to avoid that.

Using address selection or even RA ordering, you cannot specify this
policy.  But these types of policies are perfectly realistic today in the
IPv4 world.

In order to emulate this policy, I would have to specify a policy which
forced a destination address change through NAT in order to accomplish my
objective.

IMO, an absolute requirement here is that we have a policy capability
that's far greater than longest bit match or preferred order for RA
prefixes.  Policy in path selection for multihomed enterprises, at a
minimum, needs to be able to prefer or avoid certain intersections of
source and destination addresses for a given destination *host* (not
address!) that would normally be avoided or preferred.  A nice-to-have is
a policy engine that is also aware of AS-path data so that policies can be
programmed for AS preference when it involves more than one AS between two
communicating organizations.

> The only thing that doesn't happen when the host selects the locator is
> that the network administrator doesn't get to enforce fine-grained TE
> for the return traffic. If this is what we are defining as 'unnecessary
> complications', I have to question the necessity of changing the entire
> infrastructure so that it will support the arbitrary replacement of
> locators without affecting applications. That sounds a lot more complex
> to me than simply adding one more policy to the set of things the host
> administrators have to do already.

Take a look at the scenario above.  These are examples of the types of
policy that enterprises need.

/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: chuegen@cisco.com       CCIE #2100      ..:||||||:..:||||||:..