Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]

Joel jaeggli <joelja@bogus.com> Fri, 31 August 2012 14:45 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EB921F865C for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2012 07:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o23mkmXuxPvs for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2012 07:45:42 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D87F821F8650 for <v6ops@ietf.org>; Fri, 31 Aug 2012 07:45:41 -0700 (PDT)
Received: from Joels-MacBook-Pro.local (71-93-165-75.dhcp.hspr.ca.charter.com [71.93.165.75]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7VEjboD087005 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 31 Aug 2012 14:45:39 GMT (envelope-from joelja@bogus.com)
Message-ID: <5040CA3B.4090602@bogus.com>
Date: Fri, 31 Aug 2012 07:29:15 -0700
From: Joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> <50409C2A.2060805@redpill-linpro.com> <5040AC38.5080505@gmail.com>
In-Reply-To: <5040AC38.5080505@gmail.com>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 31 Aug 2012 14:45:40 +0000 (UTC)
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2012 14:45:42 -0000

On 8/31/12 05:21 , Brian E Carpenter wrote:
>> Except for altruism, that is.
> 
> Exactly. I don't believe the IETF should be making it seem that
> blowing up BGP4 is the recommended approach. We should actually be
> advocating altruism IMHO.

The IETF should make recommendations that responsible network operators
can follow without interfering with their business.

With respect to PA address space, it should be understood that some of
the internet content providers this document addresses will be deploying
from the networks of their colo providers, ASPs, cloud providers and so
on. these will be necessarily numbered out of provider assigned address
space for convenience, because the provider itself is multihomed and so
forth.

joel

> Regards
>    Brian
> 
> On 31/08/2012 12:12, Tore Anderson wrote:
>> * Brian E Carpenter
>>
>>>> «This option is available to an ICP willing to deal directly with the
>>>> relevant Regional Internet Registry and pay the associated fees»
>>>>
>>>> This is misleading, at least in the RIPE NCC service area. 
>>> Ah, OK, would it be accurate to simply delete the word "Regional"?
>>
>> Strictly speaking, I suppose so. But the message is still a bit
>> confusing. The «willing to deal directly with» formulation is in all
>> likelihood a red herring, because the ICP will be already dealing
>> directly with an LIR - his ISP. And which ICP would care about €50/year?
>>
>> The document continues in the same vein: «only large content providers
>> can justify the bother and expense of obtaining a PI prefix». Can't say
>> I agree. The bother and expense is for all practical purposes
>> negligible, especially when compared to the potential bother and expense
>> associated with renumbering out of a PA assignment down the road.
>>
>> It is probably a bigger hurdle for the ICP (compared to getting a PA
>> assignment from an ISP) to acquire and set up BGP-speaking routers.
>> However, it is also possible to have the upstream ISP(s) advertise the
>> PI prefix on the ICP's behalf, so even that might not be a problem after
>> all.
>>
>> Truth to be told I don't see any real reason why an ICP shouldn't go for
>> PI from day one. Except for altruism, that is.
>>
>> (I'm not well informed when it comes to the other four RIRs' PI
>> policies, so the above might be limited only to the RIPE service area.)
>>
>> Best regards,
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>