Subject: Re: IPv6 Multi-homing BOF at NANOG 35

From: John Payne <[email-masked]>
Date: Tue, 4 Oct 2005 14:10:27 -0400

On Sep 25, 2005, at 12:48 PM, Iljitsch van Beijnum wrote:

> NANOG = network operators in the sense of ISPs and the like. The 
> solution that the shim6 is working on does NOT apply to this 
> demographic.

Whoa there.  The NANOG community (as well as other ISP communities) is 
hugely affected by shim6.

They are the ones who will be fielding customer calls about multihoming 
- "why can't I just setup BGP like I always have done?".  Not everyone 
at NANOG is going to be big enough to get a /32, but most of the ISPs 
there are at least multihomed today.

I for one am looking forward to both the BoF and Jason Schiller's 
general session topic.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Geoff Huston <[email-masked]>
Date: Wed, 05 Oct 2005 06:42:12 +1000

>Doesn't this apply to any orgization that doesn't have its own /32?

In the fullness of time this is the expectation, yes. However its pretty clear
that the approach entails some changes to the protocol stack, and its not going
to be a completely straightforward task. So its a pretty likely outcome 
that the
'conventional' practice of advertising more specifics into the routing system
will not disappear overnight.

>Doesn't this apply to any orgization that has customers that require
>multihoming but lack their own /32 as John points out?

as above.

>Doesn't this apply to any orgization that has it's own IPv6 aggregate,
>and wants to advertise something more specific than its aggregate?
>
>If that is the case, then it won't just apply to ISPs or multi-homed end
>sites who can't get a /32, it also applies to ISPs and end sites who have
>a /32, but need to split route announcement to share load across multiple
>transit providers.

I can appreciate the logic here- but in the same way that it strikes
me that using routing to perform fine-grained traffic engineering is akin
to using a mallet and an axe for a task that normally requires a micro-surgery,
this also strikes me as a very round-about way to get to a useful approach
to realize localized traffic engineering.

regards,

     Geoff

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 5 Oct 2005 10:38:15 +0200 (CEST)

Dear all,

On Tue, 4 Oct 2005, John Payne wrote:

>> NANOG = network operators in the sense of ISPs and the like. The solution 
>> that the shim6 is working on does NOT apply to this demographic.
>
> Whoa there.  The NANOG community (as well as other ISP communities) is hugely 
> affected by shim6.
>
> They are the ones who will be fielding customer calls about multihoming - 
> "why can't I just setup BGP like I always have done?".  Not everyone at NANOG 
> is going to be big enough to get a /32, but most of the ISPs there are at 
> least multihomed today.
>
> I for one am looking forward to both the BoF and Jason Schiller's general 
> session topic.
>

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). 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

---

From: "Jason Schiller ([email-masked])" <[email-masked]>
Date: Tue, 04 Oct 2005 15:54:10 -0400 (EDT)

On Tue, 4 Oct 2005, John Payne wrote:

> Date: Tue, 04 Oct 2005 14:10:27 -0400
> From: John Payne <[email-masked]>
> To: Iljitsch van Beijnum <[email-masked]>
> Cc: David Meyer <[email-masked]>, [email-masked], [email-masked], [email-masked]
> Subject: Re: IPv6 Multi-homing BOF at NANOG 35
> 
> 

> > I urge the discussion leaders to make it painfully clear to which
> > types of users the shim6 solution space applies and to which type of
> > users it doesn't.

___Jason

---

From: Tony Li <[email-masked]>
Date: Tue, 4 Oct 2005 14:41:59 -0700

>>> solution that the shim6 is working on does NOT apply to this

The ISP community is the primary direct beneficiary of shim6 and will  
have to work with their customers to help implement it.  If the  
operational community is interested in the long term scalability of  
the routing subsystem, then we need to implement the changes to the  
routing architecture necessary to not advertise per-organization  
prefixes globally and shim6 is the best way that we have of doing that.

Shim6 needs ISP support, plain and simple.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Oct 2005 14:17:11 +0200

Mohacsi Janos wrote:
>> They are the ones who will be fielding customer calls about 
>> multihoming - "why can't I just setup BGP like I always have done?".  
>> Not everyone at NANOG is going to be big enough to get a /32, but most 
>> of the ISPs there are at least multihomed today.
>>
> 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). 

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.

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

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.

---

From: "Jason Schiller ([email-masked])" <[email-masked]>
Date: Mon, 10 Oct 2005 11:48:32 -0400 (EDT)

On Mon, 10 Oct 2005, Brian E Carpenter wrote:

> Date: Mon, 10 Oct 2005 14:17:11 +0200
> From: Brian E Carpenter <[email-masked]>
> To: Mohacsi Janos <[email-masked]>
> Cc: John Payne <[email-masked]>,
>      Iljitsch van Beijnum <[email-masked]>, [email-masked],
>      David Meyer <[email-masked]>, [email-masked], [email-masked]

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.

> 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.  

> says it will take a while to deploy and during that time we'll

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

---

From: Paul Jakma <[email-masked]>
Date: Mon, 10 Oct 2005 17:18:42 +0100 (IST)

On Mon, 10 Oct 2005, Brian E Carpenter wrote:

> 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.

The problem isn't PI addressing, it's advertising tiny prefixes in 
the routing table. PI addressing *without* global-routing-table 
visibility *would* obviously scale for routing. We just don't have a 
way to do this.

> 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.

We'll always need PI. The Independence part of PI is what people 
/really/ want. They don't want multiple-PA (they can do that already 
relatively easily). If people can not get globally-unique PI 
addresses they will use private PI space and use address translation.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The herd instinct among economists makes sheep look like independent thinkers.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Oct 2005 08:26:19 +0200

Paul,

> relatively easily). If people can not get globally-unique PI addresses 
> they will use private PI space and use address translation.

I think enterprise administrators would be happy to go one level deeper 
under certain circumstances:

  - there is a selection algorithm that works properly

  - there is the ability to switch between the two without loss of
    L4 connections

  - it can be administered easily

  - etc.  This was the a large part of why Randy Bush asked for
    draft-ietf-multi6-things-to-think-about.txt.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Oct 2005 09:45:48 +0200

Paul Jakma wrote:
> The problem isn't PI addressing, it's advertising tiny prefixes in the 
> routing table. PI addressing *without* global-routing-table visibility 
> *would* obviously scale for routing. We just don't have a way to do this.
> 
>> will take a while to deploy and during that time we'll need a PI-like 
>> approach.
> 
> 

Paul, my belief system is different, which is why I've been vigorously
supporting ULAs, shim6 and the NAP draft. My belief is that if we
provide a solution set that that avoids the need for NAT with its myriad
disadvantages, enlightened self-interest will prevail.

    Brian