[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Multi-homing BOF at NANOG 35
On Mon, 10 Oct 2005, Brian E Carpenter wrote:
> Date: Mon, 10 Oct 2005 14:17:11 +0200
> From: Brian E Carpenter <brc@zurich.ibm.com>
> To: Mohacsi Janos <mohacsi@niif.hu>
> Cc: John Payne <john@sackheads.org>,
> Iljitsch van Beijnum <iljitsch@muada.com>, iab@ietf.org,
> David Meyer <dmm@1-4-5.net>, ipv6@ietf.org, shim6@psg.com
> Subject: Re: IPv6 Multi-homing BOF at NANOG 35
>
> Mohacsi Janos wrote:
> > Dear all,
> >
> > On Tue, 4 Oct 2005, John Payne wrote:
> >
> >
> > I think most of the ISP who are seriously thinking about IPv6 have to
> > have the ability to have a multihoming solution - getting PI-like
> > address (nowadays it is /32).
Some ISPs can get their own aggregate, some are too small and can't.
Even having your own aggregate in the global routing table and
doing IPv4 style multi-homing doesn't provide you with all of the tools
you currently have in IPv4 multi-homing. Distancing all the customers of
a given provider is not quite as useful as distancing one customer prefix
behind one provider.
Having commercial customers who require multi-homing but can't get their
own prefix in the global routing table is a barrier to entry, and impacts
ISPs who have many such customers.
Commercial customers with their own prefix in the global routing table and
doing IPv4 style multi-homing doesn't provide them with all of the tools
they currently have in IPv4 multi-homing. If they are only allowed to
advertise a single aggregate, they can split load across multiple transit
providers.
>
> The point of shim6 is to *avoid* the need for PI-like space
> for multihomed sites, so that we don't do to the IPv6 BGP table
> what multihoming is doing to the IPv4 BGP table. We need IPv6
> to scale vastly more than IPv4, so this is essential.
Yes. We can put all of the IPv6 more specifics into the global routing
table, but current hardware won't scale to hold that. Its not clear that
the technology to hold the larger RIB and FIB will be available in 5
years, or if it will be cost prohibitive.
If we try to solve this in some other way then de-aggregation, then we
need to make sure it is at least as functional and easy to operate as what
we have now, or no operators will want to adopt it.
>
> I hope the proposed BOF will make this clearer. I personally
> think that shim6 will be really cool for ISPs, although as Geoff
> says it will take a while to deploy and during that time we'll
> need a PI-like approach.
>
> Brian
There are many content providers who are avoiding IPv6 as they beleive it
is not yet ready for "prime time" commerical traffic as it lacks sufficent
multi-homing capabilities. Clearly we need a multi-homing solution
now. However I am concerned that if we allow PI addresses into the global
routing table, then we begin down the path of solving the multi-homing
problem by de-aggregating. In 10 years time, there may be many
de-aggregates in the global routing table. At that time it will be much
harder to tighten the belt and get those prefixes out of the global
routing table.
Do you think that operators of commercial networks will want to switch to
shim6? Consider the current comfort level with the IPv4 style BGP
de-aggregate traffic engineering. Consider that the current approach to
shim6 is less functional than the current IPv4 style multi-homing.
Consider the the shim6 solution may be very different to operate
(configuring end hosts instead of Internet facing routers) and may
break current operational boundaries.
Shim6 as a host multi-homing solution lends itself nicely to consumer
networks all operated by few end users with few hosts, but is more
problematic to implement it in a large commerical network.
Don't miss read me. I'm not bashing shim6. I'm suggesting it needs to be
as functional as what operators currently have.
I'm also suggesting that there is a barrier to change, and if traditional
IPv4 style multi-homing is allowed to be done in IPv6 then comercial
networks may never adopt a shim6 solution.
ARIN is currently considerig PI IPv6 space. See Policy Proposal
2005-1: Provider-independent IPv6 Assignments for End Sites:
http://www.arin.net/policy/proposals/2005_1.html
It is my belief that if this policy goes through that commercial sites
will
be unlikely adopt a shim6 solution.
___Jason
>
>
>
> For end-systems/customers/enterprises
> > might agree with upstream providers to accept more specific (and
> > upstream can agree to exchange more specific inside country/region, but
> > announce aggregate to global Internet) or use RFC3178 method (using
> > tunnels) which is quite powerful technique. Any method can be
> > implemented with careful BGP routing policy configuration.
> > The shim6 is attractive method, but requires changes in host and router
> > IPv6 implementations and this requires at least 5 years to be widely
> > accepted....
> >
> > Shim6 can be a long term solution, but shorter time-frame the
> > operator/provider/user community can use existing methods to support/use
> > multihoming. We can strart using it and if there is some problem we can
> > speak up at NANOG/RIR etc meetings.
> >
> >
> > Regards,
> >
> >
> > Janos Mohacsi
> > Network Engineer, Research Associate
> > NIIF/HUNGARNET, HUNGARY
> > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98
> >
> >
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>