Subject: RE: The state of IPv6 multihoming development

From: "Michel Py" <[email-masked]>
Date: Sun, 27 Oct 2002 14:53:40 -0800

> Tony Hain wrote:
> Even if the origin node chooses an address that is
> overwritten by a border router, there is absolutely nothing
> he origin AS can do to enforce/influence the routing policy
> of the foreign network manager. As the packet gets closer,
> there might be an opportunity to create a localized gravity
> well, but only if there is no filtering going on between
> the providers. Since the origin network can't enforce reverse
> path routing decisions, the idea that the origin host is
> making any kind of routing decision is completely bogus. 

That being said, Craig has some legitimate traffic shaping concerns.
Even though the host might not make direct routing decisions, by
choosing either which of its own addresses it's going to use or which of
the destination's addresses it's going to use, the host itself takes a
traffic shaping decision, which is not something that Craig wants and I
support him on that. Add to this the extra overhead and headaches
associated with maintaining several addresses per host, it makes the
task impossible.

In short: a large organization needs to be able to engineer traffic,
which I don't realistically see happening when individual hosts can take
decisions that can affect traffic engineering.

Michel.

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 27 Oct 2002 18:50:29 -0800

Michel Py wrote:
> ...
> In short: a large organization needs to be able to engineer 
> traffic, which I don't realistically see happening when 
> individual hosts can take decisions that can affect traffic 
> engineering.

A host decision does not affect traffic shaping for the outbound
direction. The only choice it is making in that space is the dst addr,
and it has that responsibility today, even though it has no
deterministic means of making that choice. The IPv6 address selection
rules add structure to that process.

For the inbound direction, the remote and intermediate network managers
have more impact on the actual path the bits will take than the origin
choice of source addr. All we have today is the illusion that a network
manager can direct traffic toward his network. Having 1 or N addresses
doesn't change the granularity of traffic engineering, so the argument
is bogus. What it really boils down to is that nodes outside the network
manager's direct control are making a decision (any decision). This is
about trust, not traffic engineering.

Tony

---

From: Christian Kuhtz <[email-masked]>
Date: Sun, 27 Oct 2002 22:05:40 -0500

> rules add structure to that process.

maybe i got this all wrong, but...

if this means that a host is expected to make a decision which path to 
chose, i'm sorry, i don't see that happening and consider it an absurd 
notion.

the last thing i want is for an oracle server, or webserver, or whatever
to make a routing decision as to which addr or iface to use.  seems the
trend is exactly the opposite.. to get that decision _away_ from the host
and have the backbone of a given org take care of traffic management.

any type of te will have to aggregated at a higher level than hosts. 
 
some of this is a technology and architectural decision, some of this is
also real world organizational skills.  i do not want to create a rqmt 
that says that systems operations folks have to be omnipotent systems &
network wizards to configuration, manage and troubleshoot their hosts.

and i think that's exactly what you do when you push te capabilities down
to the host level.

> about trust, not traffic engineering.

nevermind that there are various bgp knobs today which allow you to do
exactly that (regulate inbound traffic) by changing what prefixes are
advertised where and how.  there is a gating factor here in today's ipv4
world in terms of the smallest chunk of addresses which can be pulled out
of a given aggregate.

thanks,
christian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Oct 2002 10:59:01 +0100 (CET)

[Can everyone please clean up those CC lists once in a while? I get two
copies of each message which really doesn't bring me twice the joy.]

On Sun, 27 Oct 2002, Michel Py wrote:

> support him on that.

There are two cases:

1. The multihoming functionality it implemented in a separate box. In
   this case, you have all the traffic engineering knobs you'll ever
   need in this box. (Which will provide much better traffic engineering
   functionality than current BGP mechanisms, although at the expense
   of more work for thix box.)

2. The multihoming functionality is implemented in individual hosts.
   Without additional mechanisms, you have to revert to rather crude
   methods to do traffic engineering: simply drop enough packets to make
   the host switch to another IP address. Alternatively, we can come up
   with a mechanism for routers to inform hosts which exit they should
   use. As I explained in an earlier message, if the routing decisions
   are also based on the source address in the packets, it should be
   possible to control both the outgoing and incoming path for each
   flow. That's pretty much the holy grail of traffic engineering.

> decisions that can affect traffic engineering.

The host controls the traffic, but that doesn't mean the host gets to
decide. The same way the driver gets to control the car, but he had
better not drive the wrong way in a one way street.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Oct 2002 12:08:10 -0800

> chose, i'm sorry, i don't see that happening and consider it 

You did miss my point which was that the routers will always decide the
path. The only thing the host decides is which entry in a dns response
it will use for the dst, and which of its addresses it will use. 

> 
> the last thing i want is for an oracle server, or webserver, 
> or whatever to make a routing decision as to which addr or 
> iface to use.  seems the trend is exactly the opposite.. to 
> get that decision _away_ from the host and have the backbone 
> of a given org take care of traffic management.
> 

Yes, and the reality is that this will happen no matter what the host
decides to use for addresses. This whole discussion is a bogon caused by
the fear that the host might make any kind of decision. REALITY CHECK:
it already does sort through the list of addresses in a DNS response,
and if it has multiple interfaces it already has to decide which of
those to use. Once the packet is in flight, the routers decide the path
because that is their job.

>  
> some of this is a technology and architectural decision, some 
> of this is also real world organizational skills.  i do not 
> want to create a rqmt 
> that says that systems operations folks have to be omnipotent 
> systems & network wizards to configuration, manage and 
> troubleshoot their hosts.
> 
> and i think that's exactly what you do when you push te 
> capabilities down to the host level.

Nobody is pushing TE to the host level, there is simply a fear that will
happen when a host chooses which of its addresses it will use as a
source.

> 
> > For the inbound direction, the remote and intermediate network 
> > managers have more impact on the actual path the bits will 
> take than 
> > the origin choice of source addr. All we have today is the illusion 
> > that a network manager can direct traffic toward his 
> network. Having 1 
> > or N addresses doesn't change the granularity of traffic 
> engineering, 
> > so the argument is bogus. What it really boils down to is 
> that nodes 
> > outside the network manager's direct control are making a decision 
> > (any decision). This is about trust, not traffic engineering.
> 
> nevermind that there are various bgp knobs today which allow 
> you to do exactly that (regulate inbound traffic) by changing 
> what prefixes are advertised where and how.  

Over a diminishing scope of influence. Yes you affect immediate
neighbors, and depending on their filtering policy, you may influence
their direct peers, but the strength of your ability to manage inbound
traffic diminishes at every policy boundary. 

Tony

> there is a 
> gating factor here in today's ipv4 world in terms of the 
> smallest chunk of addresses which can be pulled out of a 
> given aggregate.
> 
> thanks,
> christian
>