[ppml] v6 multihoming and route filters

[Stacy Taylor]

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 <marla_azinger at eli.net> 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
>
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas at netcore.fi]
> Sent: Wednesday, June 28, 2006 9:45 PM
> To: Azinger, Marla
> Cc: v6ops at ops.ietf.org
> Subject: Re: v6 multihoming and route filters
>
>
>         autolearn=ham version=3.1.2
> 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: pekkas at netcore.fi
> X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) FILETIME=[E192EE80:01C69B36]
>
> 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
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>