IETF Logo Mail Archive

Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

t.petch <ietfc@btconnect.com> Fri, 30 May 2014 17:04 UTC

Return-Path: <ietfc@btconnect.com>
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 3C2D71A6F59 for <v6ops@ietfa.amsl.com>; Fri, 30 May 2014 10:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
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 CBJNy2FMZHMz for <v6ops@ietfa.amsl.com>; Fri, 30 May 2014 10:04:17 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A34F1A02C9 for <v6ops@ietf.org>; Fri, 30 May 2014 10:04:16 -0700 (PDT)
Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 30 May 2014 17:04:05 +0000
Message-ID: <053501cf7c28$c53d51e0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Owen DeLong <owen@delong.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <m261ks7xww.wl%randy@psg.com> <53840070.90801@gmail.com> <m2y4xn7wep.wl%randy@psg.com> <53840723.8010606@gmail.com> <CAKD1Yr1O_poMR200sjU=ttRvGaeQRkC1ZfXC0Ok4uQxdq3K=NQ@mail.gmail.com> <m2mwe37tbn.wl%randy@psg.com> <CAKD1Yr2t3-vxuG=iDi4biBNFpJwuzuHgfpB74i_uydWWRV7qZg@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <m2fvjv7q4h.wl%randy@psg.com> <m1WpDcc-0000BMC@stereo.hq.phicoh.net> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <m2iooq4oqi.wl%randy@psg.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <3350A387-4F86-4445-A72E-075913E40618@delong.com>
Date: Fri, 30 May 2014 18:01:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.165]
X-ClientProxiedBy: AM3PR07CA003.eurprd07.prod.outlook.com (10.242.16.43) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143)
X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
X-Forefront-PRVS: 02272225C5
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(13464003)(189002)(199002)(377454003)(51704005)(74662001)(87286001)(89996001)(23746002)(4396001)(44736004)(83072002)(92726001)(77982001)(87976001)(92566001)(74502001)(76482001)(83322001)(50226001)(19580395003)(19580405001)(77156001)(64706001)(81816999)(81686999)(50986999)(76176999)(99396002)(81542001)(21056001)(102836001)(42186004)(81342001)(79102001)(33646001)(47776003)(44716002)(62236002)(20776003)(14496001)(101416001)(84392001)(88136002)(85852003)(46102001)(104166001)(80022001)(61296002)(62966002)(50466002)(66066001)(31966008)(86362001)(93916002)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB054; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zza8ce9zR-yt31LMhQxU7HsVhwA
Cc: V6 Ops List <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]
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: <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, 30 May 2014 17:04:21 -0000

----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
To: "t.petch" <ietfc@btconnect.com>
Cc: "Tore Anderson" <tore@fud.no>; "Brian E Carpenter"
<brian.e.carpenter@gmail.com>; "V6 Ops List" <v6ops@ietf.org>
Sent: Friday, May 30, 2014 3:44 PM
>
> Tore
>
> The fear with IPv6 is that just because one constraint on PI has been
> removed, those handing out addresses will not realise that there is
> another show-stopping constraint in the number of entries a FIB can
cope
> with, 1M being the best estimate (as before, on the RRG list) with the
> foreseeable improvements to current technology.

Yes, we need to change the fundamental way we deal with routing and come
up
with a more scalable solution than the current everyone knows every
prefix
model.

<tp>
Owen,

yes, and that is what the RRG did.  It came up with two solutions and,
being an IRTF and not an IETF WG, one solution was declared appropriate
while the other (LISP) is being developed by the IETF:-)

The key to both is that while the number of prefixes is likely to grow
beyond the capacity of routers, the number of locations involved is
likely to remain much smaller so that routing will be based on
locations, with a mapping from prefix to location prior to routing.

All in the RRG archives.

Tom Petch

However, at any likely growth rate, if we actually start working on the
problem
instead of simply inflicting limitations and calling it handled, then we
have
time to address the issue in IPv6. Hopefully the RRG will wake up and
start
addressing this issue. For now, it is out of scope for v6ops as I
understand
the WG charter.

> And I think that every SME who has lost business with the
unreliability
> of their ISP will want multi-homing and will think that with IPv6 and
PI
> the constraints have gone, and the number of such SMEs can only
approach
> 10M over time.

All the more reason this issue needs to get addressed instead of
ignored.

> So, Brian is spot on, and just as the IETF did little about IPv4
> addresses running out until the event loomed large, so I expect
history
> to repeat itself with the growth of PI in IPv6.

He’s somewhat right about the problem. He’s absolutely wrong in
believing that
the current limitations are a solution.

Owen

v2.23.0 | Report a Bug | By Email