Subject: RE: v6 multihoming and route filters

From: "Azinger, Marla" <[email-masked]>
Date: Thu, 29 Jun 2006 08:38:21 -0700

If the IETF V6ops WG doesn't give traction to this solution then this WG will push this to become resolved in other conference mediums.  The charter for IETF appears to involve this type of work and to me appears to be the most appropriate place.  

There are a large number of people who would like to open filters to /48 so we can freely multihome.  However, it is shut down comments like this that scare many people off from participating in discussion and using their voice to say what they would like to see done with routing.  I may appear as one small voice, but there are allot of unheard ones out there that agree with the /48 filter.

Due to the lack of another solution for upstream providers to provide multihoming, I see it as good solution.  I also believe that this solution should be given serious consideration.  Weigh out the pro's and con's.  Not having a solution for upstream providers to provide multihoming is a very large con for not using an available solution today. Especially since without our V6 capable networks, v6 wont be routed or used at all. 

As for swamp.  It won't be swamp if no other solution is created, and as of today their is large conflict over what solution and if that developed solution will even work.  So it may never become swamp.  And if it does, I'm sure we can adapt and overcome.

Thank you for your time
Marla Azinger
Frontier Communications

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]]
Sent: Wednesday, June 28, 2006 9:45 PM
To: Azinger, Marla
Cc: [email-masked]
Subject: Re: v6 multihoming and route filters

	autolearn=ham version=3.1.2

On Wed, 28 Jun 2006, Azinger, Marla wrote:
> I ask the V6 WG to create a "best practice for multihoming" that can 
> be utilized today.  I ask that you please insert the solution to 
> filter at /48 thus allowing "upstream providers" to provide 
> multihoming to their customers.  This solution is needed to support 
> providers creating V6 networks and this solution can easily be added 
> into Marc's "IP V6 Routing Policy Guidelines" document.

This is unlikely to get traction in the WG.  The initial draft was 
basically like that but was changed. Many people (myself included) 
opposed (and will oppose) recommeding opening filters up to /48.

Let's not create a swamp out of v6 address space with more specific 
junk.

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

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Jun 2006 07:40:28 +0000

My opinion - and please note that it is just that, not an edict of  
any kinds - is that in the final analysis it is not the IETF but  
operational reality that controls the issues here. If your customer  
will pay you enough to advertise a prefix that you don't own and to  
arrange corresponding ingress filter and route management with your  
upstream networks, you're going to do so regardless of what any RFC  
says, and it will in fact work because you will make the necessary  
business and routing arrangements to support it. That said, the level  
of effort involved will make the price fairly high, which means that  
you will not be doing a lot of this.

A "Best Current Practice" is not something with those business  
constraints, I should think.

By the way, threatening people is not a very convincing argument  
style. If you want something done, how about helping us do it, and  
honestly addressing the issues and concerns raised?

What may have applicability is Steve Deering's concept of  
Metropolitan Addressing, which it looks like someone needs to  
describe in an Internet Draft (it is in the slides at ftp:// 
ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/95jul/ 
presentations/allocation/deering.slides.ps). In short, his proposal  
was that a regional entity such as a civil community of some size  
gets a prefix and the ISPs that serve it agree to carry its routes  
such that a user can multihome within the community and outside it  
one routes to the community. This scales in the same way that  
Provider Addressing scales, with the caveats that each provider will  
have full /48 (or /56 I imagine) routes for community on the set of  
machines that serves it, and will need fairly explicit controls to  
ensure that the routing doesn't leak.

Would you like to come to the working group and discuss the issues  
with us in Montreal? I think that would be more productive than this  
discussion is being right now.

On Jun 29, 2006, at 3:38 PM, Azinger, Marla wrote:

> If the IETF V6ops WG doesn't give traction to this solution then  
> this WG will push this to become resolved in other conference  
> mediums.  The charter for IETF appears to involve this type of work  
> and to me appears to be the most appropriate place.
>
> There are a large number of people who would like to open filters  
> to /48 so we can freely multihome.  However, it is shut down  
> comments like this that scare many people off from participating in  
> discussion and using their voice to say what they would like to see  
> done with routing.  I may appear as one small voice, but there are  
> allot of unheard ones out there that agree with the /48 filter.
>
> Due to the lack of another solution for upstream providers to  
> provide multihoming, I see it as good solution.  I also believe  
> that this solution should be given serious consideration.  Weigh  
> out the pro's and con's.  Not having a solution for upstream  
> providers to provide multihoming is a very large con for not using  
> an available solution today. Especially since without our V6  
> capable networks, v6 wont be routed or used at all.
>
> As for swamp.  It won't be swamp if no other solution is created,  
> and as of today their is large conflict over what solution and if  
> that developed solution will even work.  So it may never become  
> swamp.  And if it does, I'm sure we can adapt and overcome.
>
> Thank you for your time
> Marla Azinger
> Frontier Communications
>
> X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on  
> otso.netcore.fi
> X-esp: ESP<17>=RBL:<22> SHA:<0> UHA:<0> SLS:<0> BAYES:<-5>  
> SenderID:<0> Spam
> 	Dictionary (TRU10):<0> Obscenities Dictionary (TRU10):<0>
> 	Scam Dictionary (TRU10):<0> Adult Dictionary (TRU10):<0>
> 	Embed HTML Dictionary (TRU10):<0> Float Dictionary
> 	(TRU10):<0> HTML Dictionary (TRU10):<0> URL Real-Time
> 	Signatures:<0> Spam Dictionary 2 (TRU10):<0>
> Return-Path: [email-masked]
> X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) FILETIME= 
> [E192EE80:01C69B36]
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jun 2006 17:19:17 +0200

> Would you like to come to the working group and discuss the issues  with 
> us in Montreal? I think that would be more productive than this  

Let me echo that suggestion. I think we fully understand that there is
pressure on operators, but operators need to be very, very frightened
at the prospect of a network with say 10 million enterprises all
asking for their /48 to be routed. This isn't even an alarmist
number, it's just a direct consequence of the scaling that IPv6
allows and the size of the world economy.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Jun 2006 17:55:39 +0200

On 30-jun-2006, at 9:40, Fred Baker wrote:

> operational reality that controls the issues here.

There are two issues with having people inject /48s into the routing  
system without limitations:

1. At some point in the future, the number of routes in the DFZ could  
become so large that the routing system can't support it any more.  
This is the scaling problem that many people in the IETF are worried  
about.

2. A more operational and more immediate risk is leaking of more  
specifics. Due to the way they handle their internal and external  
routing, and the relationship between the two, it's not uncommon for  
larger networks to leak internal more specific routes into BGP. This  
way, an ISP with a /16 with a number of customers that each have a / 
24 may leak those /24s. In IPv6 this is very dangerous, because a  
single ISP with a /32 can have a maximum of no less than 65536 /48s  
that can potentially be deaggregated. So one ISP could potentially  
leak a number of routes equal to a third of the global IPv4 routing  
table.

The second issue could largely be solved by giving multihomed  
customers a prefix that is shorter than a /48 and then filter out / 
48s but allow /47 and shorter. But that's not the way things work today.

> presentations/allocation/deering.slides.ps).

I've written a draft that takes this idea a bit further a couple of  
years ago, have a look at:

http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt

---

From: "Stacy Taylor" <[email-masked]>
Date: Fri, 30 Jun 2006 11:34:40 -0700

Hello,
What we are calling for is IETF support for what we perceive to be an
operational inevitability.  It is well known that carriers are market
driven.  If enough of our customers will pay for v6 multihoming, our
marketing departments will offer it, and we will have to support it.
All of that is obviously moot if other carriers are filtering on a
shorter prefix length.

The ARIN region is implementing the policy for /48s for end sites, and
these prefixes will need to be routed and globally reachable.  We all
are leery of creating the v6 swamp, but this issue is pressing and
necessary to implement v6 in the current environment.
Thank you,
Stacy Taylor

On 6/29/06, Azinger, Marla <[email-masked]> wrote:
> X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi
> X-esp: ESP<17>=RBL:<22> SHA:<0> UHA:<0> SLS:<0> BAYES:<-5> SenderID:<0> Spam
> X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) FILETIME=[E192EE80:01C69B36]
>
> _______________________________________________
> PPML mailing list
> [email-masked]
> http://lists.arin.net/mailman/listinfo/ppml
>

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 30 Jun 2006 13:59:07 -0700

Iljitsch van Beijnum wrote:
> ...

What keeps being overlooked here is that the concept of a global DFZ is
artificial, and was originally specifically intended to sort out the players
who could afford serious routers from the rest. There is no technical need
for every organization to know the gory details of every other organization,
the basis for maintain the myth is purely an ego driven desire to be
considered a peer. 

> http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt

That was good work looking at the alternatives. I have also been maintaining
one without ties to political entities, currently
draft-hain-ipv6-pi-addr-09.txt. At the end of the day we need to revisit the
assumption that the only viable aggregation unit is provider based. There
are trade-offs here, and with a small shift toward structured topology we
could put a lid on the routing table problem.

Tony