Subject: Re: Session Stability (was multi-homing vs route aggregation)

From: Jessica Yu <[email-masked]>
Date: Wed, 04 Aug 1999 11:06:12 -0400

>The section 4 says "a particular node (host) may be assigned address(es)
>out of a single prefix, or may have addresses from different prefixes".
>Then RFC 2260 seems a bit ambiguous about this question (which is not
>in fact addressed by it)... 

	Siting this sentence and concluding that this document proposes 
	or advocates multiaddress per host is a bit of stretch.  The 
	document mainly proposed is to assign address from each ISP to 
	different subset of the hosts e.g. pref-A to a subset of host 
	and pref-B to another subset.  The assignment criteria is "to 
	use the topological proximity of a node (host) to a particular 
	ISP as a criteria for selecting" as described in section 4.

	The machenism proposed in rfc2260 does not whatsoever require
	all of the hosts assigned with multiple addresses each.  It
	does not prevent someone for some reason like to do it. 
	 
>	I (again) suggest that before we jump into the multi-addressing 
>   	per host scheme, let's throughly evaluate the complication and 
>   	operation complexity associated with that.
   
>=> we jumped into it as soon as aggregation became the important thing
>in addressing...

	I do not want to be nasty here.  But How many people who already 
	jumped into multiaddress per host for all hosts in multihoming 
	sites and even single-home sites have operational and engineering 
	experiences of real networks?  Has any implication as a result
	of this been discussed?  
 
>   	We can ignore the issue but it won't go away.  Didn't we tried
>   	it before with the multihoming routing issue?  Now, we still
>   	have to face it. 
>   
>=> this issue is not ignored but I expect this is solved in host and
>router kernels (modulo address selection which is still open).

>   	In the end, it's the network operators/engineers who are deciding
>   	if IPv6 should be deployed in their networks. If they are not
>   	convinced it's operational viable, what will happen?

>=> I believe you have two concerns:
> - bugs in kernel code, for instance in router software with
>   "secondary addresses"
> - management costs
>First point should be fixed (but I'd like to have a confirmation from
>head router vendors :-). Second point is supposed to be dealt with
>autoconfigurations, A6 RRs and router renumbering.
>In any cases we should try this in the reality then to switch to
>the 6bone mailing list?
>   

Reality checking is really needed here.  Again I suggest a thorough
study is needed to evaluate the implication of requiring all hosts
in a multihoming site (now someone even suggested that for sinlge-homed
sites) with multiple addresses.  I think I've made my point clear and
should stop now. 
						
						--Jessica

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Aug 1999 13:21:57 -0500

Jessica Yu wrote:
...
>         experiences of real networks? 

Well, I did for a while, and we renumbered it too. Given the choice
between renumbering each host instantaneously, and running with
multiple prefixes for a few months (or indefinitely), I'll choose
multiple prefixes *any* time. This has been built into the IPv6 model
for ever and it isn't going to be an ugly add-on, so I see no
reason to fear it unduly. And whatever the solution for long-term
multihoming, we *must* support multiple prefixes for renumbering
purposes.

> ... Has any implication as a result
>         of this been discussed? 

Yes, the biggest worry is DNS and that is where the A6 record came from.
Since a principal objective here is perfect or near-perfect
provider aggregation, I can't see anything but improvement in
routing operations. Wouldn't IPv4 routing be easier with
perfect CIDR aggregation (one CIDR block per ISP)?

  Brian

---

From: Jessica Yu <[email-masked]>
Date: Wed, 04 Aug 1999 14:56:06 -0400

>multihoming, we *must* support multiple prefixes for renumbering
.purposes.

To me, supporting multiple prefixes and providing options for operators
(if they choose to use it while re-numbering) is very different than 
deploying a routing system which absolutely requires multiple prefixes
per host i.e. the multiple addresses on each host have to be there all
the time.  

>perfect CIDR aggregation (one CIDR block per ISP)?

But there are other mechanisms to achieve routing aggregation while not
requiring every host assigned with multiple addresses.  
draft-yu-simple-ipv6multihoming-00.txt is one of them.

cheers!
						--Jessica

---

From: Peter Tattam <[email-masked]>
Date: Thu, 5 Aug 1999 12:15:25 +1000 (EST)

> sites) with multiple addresses.  I think I've made my point clear and

Hear, Hear...

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Jim Bound <[email-masked]>
Date: Thu, 05 Aug 1999 10:23:04 -0400

>	experiences of real networks?  Has any implication as a result

I don't this is nasty at all.  I do in building IP stacks and Jessica is
correct the complexity once I have to deal with multiple addresses is an
order of magnitude more complex in software.  Then it gets even more
complex for the user mgmt folks in engineering that have to make it
appear simple.

There are some special cases for customers where having two addresses
for an interface have proved useful and that is the case of dual rail
ethernet.

Also my read of 2260 where a pipe to another ISP is permitted would also
work with one address.
 
>sites) with multiple addresses.  I think I've made my point clear and

I agree with this concern and will add I would like to see a discussion
of at a minimum how the software will work to drive this.

In the meantime we can adopt Jessica's proposal for the 6bone and it
will work.  We can discuss and define other solutions for more complex
needs we are hearing here while we deploy Jessica's draft.

I propose we just get Jessica input on her proposal as it stands if it
needs any tightening up, etc.. and get this deployed on the 6bone now.

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Aug 1999 09:51:26 -0500

Jessica,

I read your draft again yesterday (it was short enough to get through
it on my bus ride home:)

I agree with Jim. We should try to deploy this. It only solves
a subset of the problem, i.e. it only covers certain types
of outage and it doesn't help with prefix updates, but within
these limits I can't see a problem.

I think we should also try Matt Crawford's symmetric variant.

And we should also continue to develop the slightly more
sophisticated scheme presented in Oslo, and ensure that we can
support prefix updates too.

  Brian

---

From: Guy Davies <[email-masked]>
Date: Fri, 06 Aug 1999 16:28:43 +0100

> I think we should also try Matt Crawford's symmetric variant.

UUNET-UK did this last year with ATT-LABS-EUROPE for our mutual
"customer" DIT-NG.  It seemed to work within the limited scope of the
6bone activity at that time.

The issue of source selection didn't come up but it may be that we just
weren't breaking so the resillience wasn't being tested ;-)

Guy

-- 
Guy Davies				UUNET, An MCI WorldCom Company
Senior Network Engineer			332 Science Park, Cambridge, 
e: [email-masked]			United Kingdom, CB4 4BZ
t: +44 (1223) 250457  m: +44 (7771) 907481  f: +44 (1223) 250412