Subject: draft-ietf-multi6-multihoming-requirements-03

From: [email-masked] (Sean Doran)
Date: Thu, 20 Jun 2002 21:53:09 +0000 (GMT)

Hi -

   Joe has done some updates to the draft, and has been met with
silence from the WG.

   Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03?

   Failing that, please feel free to make meta-comments on whether
we should start the last call process and move the document along.

   (Remember this is a gating issue, as this document will be used
within the working group when evaluating proposed multihoming solutions,
so this draft is important, and deserving of a few minutes of reading
and commenting time).

	Sean.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 21 Jun 2002 01:52:37 +0200 (CEST)

>    Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03?

Since you ask... The requirements all seem very reasonable to me. (Many
pretty much go without saying.) I only have two problems:

- multihoming gets blamed for the global routing table bloat, while
  the number of active routes vs the number of active ASNs clearly shows
  this is only a small factor at this time

- what happens when there is no multihoming solution that meets all
  requirements? We then forego multihoming in IPv6, or ...? There is only
  a perfunctory division of the listed requirements into the classes "must
  be supported" and "additional requirements"

> we should start the last call process and move the document along.

Maybe we should have a look at the "goals and milestones" section of the
charter for guidance.

Iljitsch van Beijnum

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 21 Jun 2002 09:02:07 +0859 ()

Sean;

>    Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03?

I agree with Brian;

	My opinion: ship it. We need to get done with requirements so that
	we can proceed to look at solutions. Twiddling the requirements to
	achieve universal consensus isn't productive.

> so this draft is important, and deserving of a few minutes of reading

However, the result based not on the universal consensus should not
be used to evaluate proposals.

IMHO, in other words, attempts to ship requirement drafts was not
productive.

Simply listing up all the requirements, some of which contradicts
each other, could have been a better approach, as the result
contains contradicting ones, anyway.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jun 2002 15:04:03 +0200

Iljitsch van Beijnum wrote:
...
>   be supported" and "additional requirements"

I'd certainly expect that there is no perfect solution. The requirements are
just a checklist for evaluating solutions. That's why I said "ship it". Get it
out as Informational so that we can move on.

   Brian

---

From: Dave Wilson <[email-masked]>
Date: Mon, 24 Jun 2002 22:47:24 +0100

>    Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03?

Question about sections 3.1.2-3.1.4.

During the discussions on global-v6, a scenario came up that caused trouble.

Imagine network A does not (under current RIR rules) qualify for a /35.
Network A has routes to network B via (a) a high speed direct connection,
(b) a high-speed network and (c) an ordinary commodity internet connection.
Network A provides connectivity to a number of sites (< 200) not under its
direct control.

In IPv4, where Network A has an ASN and allocation from a RIR, BGP localprefs
enforce a routing policy which uses the high-speed connects in preference to
the commodity internet.

Does section 3.1.4 require a solution to this scenario? "class of traffic"
might just mean a protocol or could be wider, so I am not sure.

The reason I bring this up is that it is not an unusual configuration for a
national research network. If the answer is "no" then it is not necessarily
a problem with the document :) but if the group [does|does not] plan to
address it, I think it would be useful feedback for the policy groups.

Best regards,
Dave

-- 
 [email-masked]  ------- DW238-RIPE ------- GPG key: [email-masked]
 HEAnet Limited, Brooklawn House, Crampton Ave, Ballsbridge, D4 p:353-1-6609040
 "A reload a day keeps the TAC away" - Roger Gottsponer RIPE-40 f:353-1-6603666
 HEAnet's National Networking Conference http://www.heanet.ie/conferences/2001/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Jun 2002 09:40:03 +0200 (CEST)

> enforce a routing policy which uses the high-speed connects in preference to

Only for outgoing traffic. Balancing incoming traffic is much harder,
unless the networks sending the traffic cooperate.

> address it, I think it would be useful feedback for the policy groups.

A multihoming solution that doesn't provide for a way to make a
higher-bandwidth connection to be more preferred than a lower-bandwidth
connection won't fly, because it doesn't address real-world needs. There
are still many places in the world where bandwidth is expensive enough
wasting a significant amount of it is not an option.

Route selection and load balancing are mainly a problem with solutions
that require hosts to make decisions that ultimately determine routing.
(Ie. where a host must select one address out of several to communicate
with.) At some point, routing and routing policy information has to reach
those hosts. Since this doesn't exist yet, we are free to introduce all
the features we think are necessary.

However, this requires multi6 to start looking at solutions. IPv6 adoption
doesn't seem to happen at a break-neck pace, but at some point operational
needs will make multihoming happen one way or another. (How long will the
RIRs refrain from giving themselves provider independent address space,
for instance?) That genie will be hard to put back in the bottle.

Iljitsch van Beijnum

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Jun 2002 09:57:18 +0200

I think "class of traffic" would certainly include diffserv codepoints as well
as (or instead of) protocol numbers. If traffic has been classified by a diffserv
classifier before it hits the multihoming logic, that could imply that the source
and/or destination address helped to determine the diffserv codepoint and hence 
the multihoming policy.

Are you suggesting any change to the text?

   Brian

---

From: Dave Wilson <[email-masked]>
Date: Wed, 26 Jun 2002 00:13:31 +0100

> and/or destination address helped to determine the diffserv codepoint and hence 

Ok, thanks.

> Are you suggesting any change to the text?

No. Even if the text fails to include the scenario I mentioned, I am not sure
that it would be a problem. However I'd like to make sure that multihoming
expectations in the policy groups match expectations here.

Regards,
Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jun 2002 14:06:20 +0200

In fact you made me think of one possible unexpected consequence. If we allow
diffserv code points to influence multihoming policy, it would be possible for
someone who thought they were setting QOS policy to accidentally influence
multihoming policy. That's not a very welcome side effect, but it may be 
inevitable.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland