RE: Next question...

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

Craig A. Huegen wrote:
> 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.

All the host is capable of doing is selecting source and destination
locators. What is so hard to understand about; the routing system does
path selection, because the host doesn't know anything more than
locators. 

There is no difference between the host selecting the source locator
based on an RA ordering or doing that based on a defined primary. Those
are functionally the same capability. This leaves the question of
selecting destination locator, which could be random, or based on some
deterministic process. Either way the host is the one selecting the
locator. The fact that it is local load balancing vs. multi-homing is
only known in the routing system.

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

So show how that would be done without nat in IPv4. I presume this will
start by limiting the source address list to 1 choice, but there is no
clear way to avoid the bbbe & ddde services if that is what DNS returns
to the host. Yes it is easy to route the outbound to the preferred
provider despite the destination locator, but that is also true for
IPv6. The real rub comes on the return path. If the connection is opened
to the wrong address, the return traffic will not take the preferred
ingress path. Even if it is, there is no guarantee that the cost
structure at the remote site will match, so the traffic might end up on
the least preferred path anyway. 

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

Path selection is a routing function. To implement the policy outlined
above you would have to intercept and possibly rewrite all dns messages
as well.

Tony

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