Subject: RE: V6ops: IPv6 site multihoming best practices

From: "Dwight Jamieson" <[email-masked]>
Date: Fri, 16 Dec 2005 10:34:43 -0500

Brian,

I am a member of the ATIS IPv6 task force. http://www.atis.org/

The task force is developing IPv6 transition and deployment
recommendations targeted mainly at ATIS' Telco members. 

Due to the reasons you mentioned, I didn't think the deployment
strategies outlined in RFC4116 should be recommended to service
providers for site multi-homing.

Earlier in this thread, Janos Mohacsi suggested using the procedures
outlined in RFC3178. Do you see this as a viable option to recommend?

Cheers,
Dwight

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian E Carpenter
Sent: Friday, December 16, 2005 4:25 AM
To: Daniel Roesen
Cc: [email-masked]
Subject: Re: V6ops: IPv6 site multihoming best practices

Daniel Roesen wrote:
> On Tue, Nov 29, 2005 at 02:47:37PM -0500, Dwight Jamieson wrote:
> 
>>In the absence of mature protocol support for site multi-homing 
>>(shim6),
> 
> 
> shim6 is not a site multihoming protocol, and that's the one of the 
> biggest problems of it. shim6 is (supposed to be) host multihoming.

Actually, it is supposed to be for hosts inside multihomed sites, and I
would maintain that it *is* a site multihoming solution, but implemented
in the host TCP/IP stack. But it isn't yet fully specified and deployed,
so naturally there are not yet best practice recommendations. We know
that its interaction with traffic engineering practices still has to be
defined.

However, that discussion belongs over in shim6.

>>what are the best practice recommendations for an enterprise or 
>>service provider?
> 
> 
> Use BGP for what it was designed. To connect autonomous systems in the

> routing domain. There is no alternative yet, and none in sight.

We know that doesn't scale, and that was the reason the multi6 WG
existed and why we converged on a scaleable solution. But if you need to
multihome an IPv6 site today, well, yes, you probably have to use the
techniques described for IPv4 in RFC 4116. Just don't expect that to
work in a 10 billion node network.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Dec 2005 17:20:51 +0100

Dwight, here is a sequence of discussion from old multi6 list.
As you can see, it isn't clear that 3178 really meets all
needs.

     Brian

-------- Original Message --------
Subject: RFC 3178 mh (was Re: I-D ACTION:draft-huston-multi6-architectures-00.txt)
Date: Mon, 24 May 2004 11:38:06 +0200
From: marcelo bagnulo braun <[email-masked]>
To: Pekka Savola <[email-masked]>
CC: Multi6 List <[email-masked]>
References: <[email-masked]>

Hi Pekka,

A couple of questions about RFC 3178 multihoming...

El 20/05/2004, a las 10:21, Pekka Savola escribió:
[...]
 >                                      However, this draft does not
 >          address another major drawback of the RFC 3178 approach, that
 >          it does not protect against the complete failure of one or
 > more
 >          connected ISPs.
 >
 > ==> I think this is something where one should make a reality check.
 > How often is it that the _whole_ ISP fails?  Pretty much _never_,

IMHO the problem is that RFC 3178 multihoming situation not only fails
when the complete ISP fails, but it also fails when
- one of the access routers of the ISPs fail,
- one of the exit routers of the site fail
- one of the links between the ISPs and their upstream provider fail

While i agree that probably the complete failure of the ISP may be a
low probability event, i guess that the above mentioned events may be
more common.

The other reality check that i would like to do is how common is RFC
3178? if it is not very common, what do you think are the reasons for
its non adoption?

Regards, marcelo

 >
 > unless you count 1-man small ISPs which don't even have redundant
 > connectivity and routers (and we shouldn't care about this).

-------- Original Message --------
Subject: Re: RFC 3178 mh (was Re: I-D ACTION:draft-huston-multi6-architectures-00.txt)
Date: Mon, 24 May 2004 12:45:32 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Multi6 List <[email-masked]>

On Mon, 24 May 2004, marcelo bagnulo braun wrote:
 > El 20/05/2004, a las 10:21, Pekka Savola escribió:
 > >
 > [...]
 > >                                      However, this draft does not
 > >          address another major drawback of the RFC 3178 approach, that
 > >          it does not protect against the complete failure of one or
 > > more
 > >          connected ISPs.
 > >
 > > ==> I think this is something where one should make a reality check.
 > > How often is it that the _whole_ ISP fails?  Pretty much _never_,
 >
 > IMHO the problem is that RFC 3178 multihoming situation not only fails
 > when the complete ISP fails, but it also fails when
 > - one of the access routers of the ISPs fail,
 > - one of the exit routers of the site fail
 > - one of the links between the ISPs and their upstream provider fail
 >
 > While i agree that probably the complete failure of the ISP may be a
 > low probability event, i guess that the above mentioned events may be
 > more common.

No, this is definitely not the case.  The first two bullet points are
only valid if site site does not have tunnels to from the other exit
routers to the other ISPs (or the tunnel is terminated at the ISP to
the same router as the physical link), right?  The third point is only
valid if the ISP has only one link to an upstream provider -- and no
self-respecting ISP has only one upstream link.

 > The other reality check that i would like to do is how common is RFC
 > 3178? if it is not very common, what do you think are the reasons for
 > its non adoption?

True enough.  I don't think there is sufficient evidence to make
conclusions of this, as the number of v6-enabled enterprises which
don't have IPv6 /32 prefixes (but which multihome w/ v4) is very
low..?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

-------- Original Message --------
Subject: Re: RFC 3178 mh (was Re: I-D ACTION:draft-huston-multi6-architectures-00.txt)
Date: Mon, 24 May 2004 12:22:54 +0200
From: marcelo bagnulo braun <[email-masked]>
To: Pekka Savola <[email-masked]>
CC: Multi6 List <[email-masked]>
References: <[email-masked]>

 >>
 >> IMHO the problem is that RFC 3178 multihoming situation not only fails
 >> when the complete ISP fails, but it also fails when
 >> - one of the access routers of the ISPs fail,
 >> - one of the exit routers of the site fail
 >> - one of the links between the ISPs and their upstream provider fail
 >>
 >> While i agree that probably the complete failure of the ISP may be a
 >> low probability event, i guess that the above mentioned events may be
 >> more common.
 >
 > No, this is definitely not the case.  The first two bullet points are
 > only valid if site site does not have tunnels to from the other exit
 > routers to the other ISPs (or the tunnel is terminated at the ISP to
 > the same router as the physical link), right?

Well, this is possible but this is not described in RFC 3178 and it
imposes additional configuration, for instance of the IGP of the ISP.
But i agree that it is possible to support this configuration, with
some added complexity. My point was aimed to identify another possible
cause for the non success of this solution, which could be related to
operational complexity? I mean, tunnel management, and added features
like the support for additional failure modes may require additional
manual configuration, which may make the solution less attractive.

 > The third point is only
 > valid if the ISP has only one link to an upstream provider -- and no
 > self-respecting ISP has only one upstream link.
 >

Well, you are assuming that very small sites will obtain its own
address block from the RIR, which may not hold, i guess

 >> The other reality check that i would like to do is how common is RFC
 >> 3178? if it is not very common, what do you think are the reasons for
 >> its non adoption?
 >
 > True enough.  I don't think there is sufficient evidence to make
 > conclusions of this, as the number of v6-enabled enterprises which
 > don't have IPv6 /32 prefixes (but which multihome w/ v4) is very
 > low..?

Well, i guess this is an important issue to understand, since if rfc
3178 multihoming is enough for some small sites (for instance), the new
solution should be focused to satisfy the needs of the remaining sites
(medium/big) sites, and the scalability required may be different.

In other words, understanding the reasons why rfc 3178 is not a good
option may provide us good information for the design of the new
solution, especially w.r.t to deployability.

regards, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Fri, 16 Dec 2005 21:04:20 +0200 (EET)

> As you can see, it isn't clear that 3178 really meets all

Brian, I think the two important needs we should see from that 
discussion:

  1) "RFC 3178 might be too complex to set up or use" (operational 
complexity of tunnels, tunnel overhead, etc.)

  2) folks want independence, i.e., PI addresses

Shim6 doesn't meet the need 2) either, while it may help a bit with 
1).  I don't know if 1) would be too big of a hurdle if folks didn't 
need to consider 2).

> Subject: RFC 3178 mh (was Re: I-D 
> ACTION:draft-huston-multi6-architectures-00.txt)
> Subject: Re: RFC 3178 mh (was Re: I-D 
> ACTION:draft-huston-multi6-architectures-00.txt)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--1589707168-604668325-1134759860=:11968--

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 Dec 2005 15:02:31 +0100

Pekka Savola wrote:
> Brian, I think the two important needs we should see from that discussion:
> 
> Shim6 doesn't meet the need 2) either, while it may help a bit with 1).  
> I don't know if 1) would be too big of a hurdle if folks didn't need to 
> consider 2).

Independence of what? With agile multihoming, you don't need your
prefix to be independent of your ISP; the argument is circular.
If you want stable internal addressing, you can use an SLA prefix.

    Brian

---

From: [email-masked]
Date: Sun, 18 Dec 2005 16:39:18 +0000

> If you want stable internal addressing, you can use an SLA prefix.

	perhaps, just perhaps, independence is only one aspect
	ofthe concern.  there is also the desire to have a persistant
	and consistant identifier for SNMP, AAA, RADIUS, SYSLOG, etc.
	and nearly all the renumbering or "agile multihoming"  proposals
	to date do NOT meet the requirements to use these types of 
	tools.

	the more metaphysical discussion about creating a subordinate
	reduced functionality class, walled gardens, and captive rate payers, 
	as fundamental attributes of the Internet of the 21st century as distinctly 
	different than the "level playing field" of the Internet of the
	20th century will be left to other threads.

--bill

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 19 Dec 2005 09:40:49 +0100 (CET)

On Fri, 16 Dec 2005, Pekka Savola wrote:

> 1) "RFC 3178 might be too complex to set up or use" (operational complexity 
> of tunnels, tunnel overhead, etc.)
>

In my opinion setting up a tunnel not so complex. It is fact of life in 
IPv6 Internet (and also in VPNs). The overhead and management of tunnels 
is not very good, however RFC 3178 is an attractive solution:
You allocated prefix (e.g. /48) is "virtually provider independent" until 
your allocating ISP is in business and has an IPv4 connectivity with your 
other Internet providers.

And also gives time to shim6 to be deployed which requires signifact 
changes in operating systems......

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

> Shim6 doesn't meet the need 2) either, while it may help a bit with 1).  I 
> don't know if 1) would be too big of a hurdle if folks didn't need to 
> consider 2).
>