IETF Logo Mail Archive

Re: graceful renumbering of CPE networks

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 27 February 2019 20:15 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68561310A8; Wed, 27 Feb 2019 12:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 38we4uhcQ6PA; Wed, 27 Feb 2019 12:15:08 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1911277CC; Wed, 27 Feb 2019 12:15:07 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 27D28380BE; Wed, 27 Feb 2019 15:15:01 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id D48755D4; Wed, 27 Feb 2019 15:15:04 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D22B45BE; Wed, 27 Feb 2019 15:15:04 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6man WG <ipv6@ietf.org>, 6man-chairs@ietf.org
cc: "Bernie Volz (volz)" <volz@cisco.com>, Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: graceful renumbering of CPE networks
In-Reply-To: <alpine.DEB.2.20.1902261829250.24327@uplift.swm.pp.se>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <433607c1-dbc6-a42e-cb17-dc209e33bdaa@si6networks.com> <12EA4FAE-BE3D-4CFE-9837-DF052F79A998@employees.org> <F48A816A-983E-4375-834C-75F103DCEA6A@employees.org> <8c8a79cf-0a87-15bc-bd91-bd2da82fdfa1@si6networks.com> <9BE77D1D-C247-4B8E-B9A F-22BE1DC9F79D@employees.org> <CAKD1Yr1fv3pUevB_zeZpQ-UQcNUo2zHUH4xj9NXYohyMbUSgRQ@mail.gmail.com> <25657.1550676340@localhost> <716de09a-2436-f0c7-c607-bdfef35880b1@gmail.com> <7014.1551050774@localhost> <90DA6A7F-783B-4548-861F-21DACF780D81@employees.org>, <alpine.DEB.2.20.1902261422330.24327@uplift.swm.pp.se> <D25E950E-8C35-407D-A286-C4DF3A9811A1@cisco.com> <alpine.DEB.2.20.1902261513510.24327@uplift.swm.pp.se> <BN8PR11MB360181A24A0CFC91D571F48ACF7B0@BN8PR11MB3601.namprd11.prod.outlook.com> <alpine.DEB.2.20.1902261648430.24327@uplift.swm.pp.se> <BN8PR11MB36010F74632ECB4B920DA140CF7B0@BN8PR11MB3601.namprd11.prod.outlook.com> <alpine.DEB.2.20.1902261829250.24327@uplift.swm.pp.se>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 27 Feb 2019 15:15:04 -0500
Message-ID: <420.1551298504@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OMJEgLsLF0xNyc58IRoDhtikvYY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 20:15:11 -0000

Chairs,
in the context of discussion of https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
(which has received a ridiculous amount of ML traffic), I'd like to have some
discussion in 6man at IETF104 about how we can signal orderly renumbering of
CPE devices that use DHCPv6-PD to get their addresses.

Possible outcomes that I can see:
   1) 6man needs to take RFC7084 BCP and make some standards documents,
   2) dhc WG needs to write some BCP document
   3) we need to encourage RIPE, Broadband forum, or CableLabs (or all of
      them), to write new documents referring to existing technology.
   4) we need to write a problem statement because there combination of
      problem areas goes beyond PPPoE vs CMTS/FTTH/ethernet in terms
      of it's combinatorics.

But it's clear as 6man-slaac-renum has pointed out that every renumber and
some reboots look like flash renumbering to end-hosts even when they don't
need to be so abrupt.



Mikael Abrahamsson <swmike@swm.pp.se> wrote:
    >> Why would a Reconfigure be done here? This seems more like this would
    >> require the HGW to get a new lease (i.e., Solicit). I'm not sure how the
    >> move would be done without causing the link state to have changed to
    >> trigger some kind of action at the HGW to restart DHCP (perhaps with
    >> Confirm or Rebind).

    > There are plenty of deployment scenarios where all kinds of things can happen
    > without the link layer going down and up again. Please read
    > https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/ for
    > one.

    > --
    > Mikael Abrahamsson    email: swmike@swm.pp.se

    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email