Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?]

George Michaelson <ggm@algebras.org> Fri, 13 November 2015 00:58 UTC

Return-Path: <ggm@algebras.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC041B3B82 for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 16:58:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHe7JUBYMq4X for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 16:58:04 -0800 (PST)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E341B3B74 for <v6ops@ietf.org>; Thu, 12 Nov 2015 16:58:03 -0800 (PST)
Received: by qkao63 with SMTP id o63so33187481qka.2 for <v6ops@ietf.org>; Thu, 12 Nov 2015 16:58:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GiPfwGBZ7VSSQ5PhvwJYqEps827TbTrWXXA1bkwD0cg=; b=C6APqSn0ENDNfVZb7aPfDTajtMGlOrHSS8F8+1Kx20m9FpNkgOyVuQJQ97BDvJ/dgu Y2v4Wqc3jHlm9ZBGupMPoBsykHwkMMkxTRyRo1TD5u8BqQ0kiYtjYi507rJQSJxi99jE uJ5cuYVIjT5GlKH2R+llJqloqdVkRJK7JgGAbCDbCSuUs8vPTXy5YToR0fDZ8DiiP9se 9FmW3Jz8Rsxu5vxEbmK6XMnck5rRliTwKeUEu/8susKMa/IJYjcX/S1+CnE4r4NGtgW5 L99xn0bIROmxd7PkpJ/R+BtobTVHmLFzFxxYZqO0Db5xpoteHE8sfY5rWmMnj1ksqAwh AVdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GiPfwGBZ7VSSQ5PhvwJYqEps827TbTrWXXA1bkwD0cg=; b=AnSzKUbui6fGWyHu3qaNfh0lo9FCE/YxDY4nWtmLJo3BscLOR1fO/9jX42MrjrHSA8 OCrdwTuhwJvlxpiLBw4fUj1jYCP8os/fyKdycdjREBHTtJPZ2wwTkXyPaknyYbKPvkR9 fZCz8DkUW289mEv/rVizEGp3ox0L9gSJGrTiTeDFAP5CuW2yWFjAGv+k6ANxARB8vg24 ITGkSKVbUUacfVqx+RLvy6vTYfBLjRX5DGgVpBF1p8czoeFzsntyB52Maj3+heGKiczJ c4ipgEEiNAbcz/Vvd4zeZYvVkzNQq6yigFgB0rYWFV+riWJ7LSZ67egEZbG14VaFA0AH C4+g==
X-Gm-Message-State: ALoCoQmKilLAePp/5bVywVLhci9Kj6JgRBFOmBZ0JwXYG5tCz9ILNmeW1TVI/Vgc6slznwGQzPxQ
MIME-Version: 1.0
X-Received: by 10.55.18.154 with SMTP id 26mr19016906qks.0.1447376283040; Thu, 12 Nov 2015 16:58:03 -0800 (PST)
Received: by 10.55.80.66 with HTTP; Thu, 12 Nov 2015 16:58:02 -0800 (PST)
X-Originating-IP: [2001:dc0:a000:4:bc01:949f:ac2b:4e77]
In-Reply-To: <56453026.3090607@gmail.com>
References: <Pine.LNX.4.64.1511050424410.1055@moonbase.nullrouteit.net> <20151106.063106.74659839.sthaug@nethelp.no> <CAO42Z2x3O8A1XKqN3PTcvM=xpF8W_WNSL1rVhHQ4ZY5HbVG=OQ@mail.gmail.com> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <5644EE46.7000805@gmail.com> <CAKr6gn1KokTGJ0cg70OR=q8Uv-1mr7TmjcYJwLVgsK_3i6tcpw@mail.gmail.com> <56453026.3090607@gmail.com>
Date: Fri, 13 Nov 2015 10:58:02 +1000
Message-ID: <CAKr6gn36acXca_fEgkGP-gm_crovTiCXzuNhXc1MhTA45w20kg@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="001a114584da3510420524618d01"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/oURJ_9Rwj0uBVs-bdTDBp5q4FjY>
Cc: "<v6ops@ietf.org>" <v6ops@ietf.org>
Subject: Re: [v6ops] PI heresy [draft-ietf-v6ops-ula-usage-recommendations - work or abandon?]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Nov 2015 00:58:06 -0000

Since I work in the governance side, I have to be clear that I have no
voice in policy in RIR land, this is just my personal opinion.

But my personal opinion is that we are not facing a CIDR scale problem in
this niche, and probably don't need to act like we are.

My reason is simple: CIDR was about exhaustion as much as about routing. We
have only half the problem, and even that is (in my opinion) tendentious.
We *may* have half the CIDR problem, but its a may, not a *do*. -Therefore,
applying CIDR logic to the address management process in V6 is not (yet)
justified.

Contrariwise, we have an uptake problem. We should be encouraging uptake of
IPv6, and if pushback from network-literate SME's is that they are
concerned about capture behind a PA then we should admit PI processes, and
not be over-pessimistic about the cost in future routing terms of PI to SMEs

Rather than asking BGP/Router people "can you make a router now for 100m
prefixes" we should be saying "if we can forsee 100m prefixes in 5-10 years
time, can you get there, and if not, what models of prefix management would
work for you"

I think this is a corollary of what John Scudder did in IEPG: we need the
conversation with the ASIC people to be framed the right way.

-G


On Fri, Nov 13, 2015 at 10:34 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:
>
> On 13/11/2015 13:20, George Michaelson wrote:
> > I'm sorry Brian, but as I said in another reply, this is just specious.
> > It's true in as much as IF all SME's wound up in BGP we'd have a
heat-death
> > problem.
> >
> > But a) they won't arrive tomorrow, or next year: it takes time,  and b)
> > other solutions to routing will emerge.
>
> No doubt. But Mark is correct: we have to defer the crisis until the
solution
> is available. We deferred it once by introducing CIDR 20 years ago.
Encouraging
> PI for all customers is antiCIDR, and that's a problem.
>
>    Brian
>
> > Like, giving them scoped /48 out of
> > a block which has export limits under some covering prefix, and limits
the
> > local visibility of their BGP independence to within some constrained
> > context.
> >
> > It never ceases to amaze me that I tell a yak-herder my BGP failures,
> > forcing local path selection, with no subsequent alteration in routing
of
> > concern to them, *and we're not even shipping packets*
> >
> > Tony Hain amongst others proposed models of geographic and scoped
> > assignment which were shot down in flames by the usual suspects. Because
> > its "not how we do it now" people don't like talking about this
sensibly,
> > but there are rational models of address management which preserve BGP
like
> > behaviour, but don't expose all routing decisions globally, that only
have
> > local meaning.
> >
> > G
> >
> >
> >
> > On Fri, Nov 13, 2015 at 5:53 AM, Brian E Carpenter <
> > brian.e.carpenter@gmail.com> wrote:
> >
> >> Please let's not pretend we're discussing the ULA draft any more.
> >>
> >> On 13/11/2015 07:32, Owen DeLong wrote:
> >>
> >> ...
> >>> How is a /48 PI hard to acquire? Where?
> >>
> >> As others have implied, that isn't the point. The point (and I expect
> >> we had this argument on the RRG list some years ago) is that we can't
> >> put 10,000,000 /48 entries into BGP. So if we go around encouraging
> >> all small enterprises to get a PI prefix we are all doomed.
> >>
> >>    Brian
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >