IETF Logo Mail Archive

Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds))

Mark Smith <markzzzsmith@gmail.com> Tue, 12 November 2019 22:29 UTC

Return-Path: <markzzzsmith@gmail.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 E61161200B9 for <v6ops@ietfa.amsl.com>; Tue, 12 Nov 2019 14:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dnzaACrro_6F for <v6ops@ietfa.amsl.com>; Tue, 12 Nov 2019 14:29:18 -0800 (PST)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 2F62D120018 for <v6ops@ietf.org>; Tue, 12 Nov 2019 14:29:18 -0800 (PST)
Received: by mail-oi1-x230.google.com with SMTP id 14so10404093oir.12 for <v6ops@ietf.org>; Tue, 12 Nov 2019 14:29:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TijewTMMh40ZlbPDx075DZAeoG3EFJx6bZskP8OxhVc=; b=lwXPbMVg1d3ahw9EYwLVuJ+E9kFPhn5OPopae3bBoppjQke1+G7qpIWSgFvrxF0lQt eqiz7Uj8yLkXECb+C/wZ1tnkH5TvmlhsvqbPrTC/loH4RDQzofwiTqMio8Y1vm+Wy2n7 9nwDfrUx5JNeb60bjKP2IpikZKeukTl7lQTAfpovTh9+cuJPCCkh2emeA+xkU5k2E4Ml HgeNjx0G/6YeFiJZbVZAdMJgVklhg/gh47mNTqeh+evBP+G7EudV9M4W19iOPTsNSNBp ewEpWNcFpY8xkNwLL5Ny0q8tUKZdg2situ60ZjT2DIjt054dcBAwDRpkOMZKzxshZDXY VIqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TijewTMMh40ZlbPDx075DZAeoG3EFJx6bZskP8OxhVc=; b=L/6tnTt8yDdi5dz/QqxAlhbTJSq8GaP2Xbs9Z/FNMRmIKU03w9RWWCWF+ZaR25YfLT 6UwNEuA3yHmA57osYCAt8j++oRMzg9JSCkoiGEIToOQQlC9gVxprkv9URYedsogJm4b7 +WotcF8WQLmEw/quYd6IrtFj0emPBj2cKEsycbCRHnoLUqksG126PUCUT5C7ydHdjA6W 10ufeGykaqnvoEWp2yNJUokgK8WbVeWYbBpImPxoTzcLLSARw9d/S0OWyKA5wJudJkYh 8xyjYT5ofOhbHbBfd534dySoar478gGWWfdbPWfKPzWTWpLSGU0Z+ao7NzViPeHlenH/ R5IA==
X-Gm-Message-State: APjAAAW5Q0IsSkP/LRbecvxkvg6Prwntg35/CWO9R5F++6XWVDOL5vRn e57sRVUiDRk9+JdlauDl9y03yMee649FNRphGFMrHH+i
X-Google-Smtp-Source: APXvYqwLZJritdiSEPRUmiwhvHnltnxk+la1sPEa91mn4COebbUkr2jt3BkZmylBDX1EeGn9TR1BpBuYI9E9FqgW1Ps=
X-Received: by 2002:aca:f553:: with SMTP id t80mr70813oih.60.1573597757402; Tue, 12 Nov 2019 14:29:17 -0800 (PST)
MIME-Version: 1.0
References: <CAHL_VyBC3NbT4b-mnacU+ZmzyXus4HXcKx9ykdWJ3_a2uJCi4g@mail.gmail.com> <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <CAO42Z2zWTediRkaF_pfot_QT9Hsf5Wdu9_77BQZjEEG5wY1jdQ@mail.gmail.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com> <CAO42Z2zTBXCA7HVBYfXsZFC91-Ac5h6m4fAvgBFPHz8xTfNZTA@mail.gmail.com> <6aca00b4-2502-0c64-cf9a-78184f32ddcc@forthnet.gr> <2c95e214-7a64-311a-e856-d5891dda260d@si6networks.com> <d01e7f5c-2415-6271-f6ac-1775f2bbf900@forthnet.gr>
In-Reply-To: <d01e7f5c-2415-6271-f6ac-1775f2bbf900@forthnet.gr>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 13 Nov 2019 09:28:49 +1100
Message-ID: <CAO42Z2w7_yB+5C+uKjuzuBxxjgOpM4HKjUx6554+S-wdKPPfiw@mail.gmail.com>
To: Tassos Chatzithomaoglou <achatz@forthnet.gr>
Cc: Fernando Gont <fgont@si6networks.com>, v6ops list <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LVc0s8kFlcKy5NXjEZxzxwqDBZ4>
Subject: Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds))
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 12 Nov 2019 22:29:20 -0000

On Wed, 13 Nov 2019 at 08:20, Tassos Chatzithomaoglou
<achatz@forthnet.gr> wrote:
>
>
> Fernando Gont wrote on 12/11/19 16:33:
> > On 12/11/19 04:11, Tassos Chatzithomaoglou wrote:
> >
> >> The subscriber should have the choice to decide and the technology should give the means to support his/her choices.
> >> We're building a page inside our subscriber portal, where the subscriber chooses how frequently the LAN IPv6 assigned prefix should change.
> >> Default is to change at every PPP reconnect, but the subscriber can choose specific periods (x weeks/months) or action (once at next reconnect).
> > So, upon a CPE crash and reboot, the subscriber would get a different
> > prefix. Right?
> >
> > Thanks!
> >
> > Cheers,
> Yes, the current default is for the subscriber to get a different prefix after a CPE crash and reboot (like in IPv4).

"like in IPv4"

Why are you giving customers delegated IPv6 prefixes - that's not like IPv4?

Other than "like in IPv4", why are you making the PD prefix change
upon reconnect when you don't have to?

What if your competitors provide stable prefixes, and their customers
get a better service experience than your customers do, without having
to wait possibly years for CPE and/or host upgrades per this ID's
proposal?

What is stopping them doing that? If they already have stable prefix
supporting infrastructure, why wouldn't they switch it on when they
can, when it could mean stealing customers from you and reducing their
numbers of helpdesk calls?


>But a CPE crash is not a common case. The most common case for prefix change is a DSL disconnect (due to line issues) or a PPP disconnect (due to network issues).
> Also, many of our CPEs store internally the prefix, so after a PPP reconnect they inform the LAN hosts about its release.
>
> --
> Tassos
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email