draft-ietf-multi6-multihoming-requirements-06.txt

[Randy Bush <randy@psg.com>]

i think i want to remove it from this week's agenda

randy

---

From: Randy Bush <randy@psg.com>
To: multi6@ops.ietf.org
Subject: RE: draft-ietf-multi6-multihoming-requirements-06.txt
Date: Thu, 12 Jun 2003 04:53:05 +0900

An Ops-Dir reviewer had the appended comments.  excuse the droll
phrasing.  any chance we could address them?

randy

---

Let's see: load balancing is not a realistic requirement.  For the
architecture to be automatic, we have to be dynamic and we've
proven that we don't know how to do that yet.  Even to give people
some tools seems to lead to abuse.  Who controls the balancing? 
The source?  The destination?  Don't say 'both'.  No packet can
serve two masters.

Performance.  Exact same arguments since the only way to affect
performance is to load balance.

Policy: so ill stated as to be meaningless.  If this is a call
for policy routing, that's fine, but it has nothing to do with
multihoming.

Simplicity: motherhood, apple pie and chevrolet.

Transport survivability: Well, ok, but this is just a refinement
of the redundancy requirement.  How about we remove the redundant
redundancy
requirement?

Compatible with DNS: meaningless

Packet filtering: meaningless

Scalability: see simplicity

routers: create a new architecture, but don't change the routers, change
the hosts

hosts: create a new architecture, but don't change the hosts, change the
routers

Interaction between hosts & routers: tighter coupling between subsystems
has never been an architectural good idea.  So let's do that and change
both.

O&M: see pie, apple.

multiple solutions: please don't give us one size fits all, that's
not confusing enough

security: don't break security

Net:
The real requirements are:

	- Provide multihoming
	- Provide scalable routing
	- Transport survivability