Subject: Requirement document last call (let's focus!)

From: "Christian Huitema" <[email-masked]>
Date: Thu, 3 Jan 2002 09:01:35 -0800

> | This sounds exactly like a description of mobility, and exactly like
> | a description of multihoming. I don't think we should be scared of
> | common solutions (which is not the same as saying MIPv6 is the
> | solution for multihoming).
> 
> Remember that this WG is charterd to solve SITE multihoming,
> rather than host multihoming.   If the former, which implies
> simultaneous connectivity and/or migration for a collection of
> hosts from a few to a vast number, can be done using the mechanisms
> of the latter (e.g. multi-addressed hosts, MIP6), that's fine and
> dandy.  However, first, the charter documents need to be pushed
> along the standards track, as discussed in SLC.

Seconded!

Let's first achieve the goal of the current charter, which is to publish the requirement document. And let's not try to tailor the requirement to a specific solution: this is the known way to not make progress.

Could someone summarize the actual modifications to the requirement document that surfaced during this last call? I seem to recall the following:

1) Tony Hain sent several detailed comments, one of which generated a strong debate, i.e. his objection to a part of section 3.1.2 that stated that "a site MUST be able to distribute ... outbound traffic between multiple transit providers," arguing that this was a site policy matter. I personally don't agree with Tony, and believe the solution must enable the site to balance traffic, and must also enable the site to not do so if it chooses.

2) I pointed out that different classes of solutions have different scaling properties, which implies that the solution for multi-homing my home network to cable and DSL may not be the same as the solution for multi-homing Microsoft's network. Don't know whether that should be part of the requirement document.

3) The discussion on renumbering and EID pointed out the need to add a requirement that "the solution shall not depend on instant updating of the domain name system", or if you prefer that "the solution should be compatible with the observed dynamics of the current DNS system."

4) Naïve implementations of EID and MIPv6 tend to introduce a dependency on a name server or a home agent, i.e. another point of failure. If people want to pursue this path, we should make sure they do it the smart way, i.e. do not introduce a dependency on another system beside the site-exit router and the multiple providers. That may be worth spelling out in a requirement.

Do you agree that this is a fair summary of the discussion on the requirements draft? I yes, we should maybe have a short editing pass, and then proceed towards publication of the requirements and rechartering of this group.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jan 2002 10:53:14 +0100

Correct. I had proposed adding

 The solutions must include an analysis of their effects, if any, on DNS updates,
 including consideration of load for the global updating of the DNS, and
 interactions with DNS TTL and caching.

which people seemed to agree with.

  Brian

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 4 Jan 2002 09:38:24 -0800

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
>  interactions with DNS TTL and caching.

DNS AAAA records are a good starting point
http://www.dot-biz.com/INFO/Papers/IPv4Plus6/

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 7 Jan 2002 14:40:19 -0800

Christian Huitema wrote:
> 1) Tony Hain sent several detailed comments, one of which
> generated a strong debate, i.e. his objection to a part of
> section 3.1.2 that stated that "a site MUST be able to
> distribute ... outbound traffic between multiple transit
> providers," arguing that this was a site policy matter. I
> personally don't agree with Tony, and believe the solution
> must enable the site to balance traffic, and must also enable
> the site to not do so if it chooses.

I was arguing that outbound traffic balancing is a local site policy
matter, and nothing we do will change that. The site will send the bits
out whichever interface it chooses, and the only thing this group could
do to influence that would be to define a negotiation protocol (PNI
like) to automate changes in site policy.

The other point is that for inbound load balancing, the receiving site
only has control as long as it does not conflict with origin site
policy, or the topology is deep enough that an intermediary abstracts
out the differences. The receiver can advertise detailed routes over
each specific link, but if the origin ignores those and defaults to its
prefered low-cost provider, the traffic is not likely to balance the way
the receiver wants. Yes we can require an approach that allows a
receiver to balance in the abstract, but there is no way to achieve
fine-grained absolute control without signalling/negotiation between the
endpoint sites, likely to be followed by some form of path establishment
protocol.

Tony

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 8 Jan 2002 08:35:06 +0859 ()

Tony;

> like) to automate changes in site policy.

I agree with you.

A site CAN NOT be prohibitted to control outbound traffic.

Any proposal automatically allows sites distribute ... outbound traffic
between multiple transit providers.

So, the requirement is meaningless and should be removed.

> out the differences.

Again, I agree with you.

> The receiver can advertise detailed routes over

But, it will make routing/signalling information not to scale,
which destroys the purpose of multi6.

So, the requirement should be

	A proposal MAY allow site weakly control inbound traffic but it
	MUST NOT increase the amount of global routing/signalling
	information traffic.

My feeling is that, in a sense, BGP already is an overkill.

							Masataka Ohta