IETF Logo Mail Archive

RE: graceful renumbering of CPE networks

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 26 February 2019 15:53 UTC

Return-Path: <swmike@swm.pp.se>
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 B3E02129532 for <ipv6@ietfa.amsl.com>; Tue, 26 Feb 2019 07:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 EKeF7prERrVR for <ipv6@ietfa.amsl.com>; Tue, 26 Feb 2019 07:53:02 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B5A128CB7 for <ipv6@ietf.org>; Tue, 26 Feb 2019 07:53:02 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 37FDAB2; Tue, 26 Feb 2019 16:53:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1551196380; bh=nZ/I/qEhF4AZ+8RNUD1cZuAbKdkVU7LmJmCPIXlribY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=JspDOxW/I7Chlq5WbBz6atLXEMFSZ7c/ke7vSJGRgEQyxARTA0HgOJGYhTCaQdPlp AJfQ7pjr633Yf2QIzLrS50L6co7Wg49Kxpo4kVOEh1bjZWgISzEI+G5h1HCfxspWBS 8+GZHdKmr3cPFrtbesohPJ5wfhAibpKq76dLtJC8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3554CB0; Tue, 26 Feb 2019 16:53:00 +0100 (CET)
Date: Tue, 26 Feb 2019 16:53:00 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Bernie Volz (volz)" <volz@cisco.com>
cc: Ole Troan <otroan@employees.org>, Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
Subject: RE: graceful renumbering of CPE networks
In-Reply-To: <BN8PR11MB360181A24A0CFC91D571F48ACF7B0@BN8PR11MB3601.namprd11.prod.outlook.com>
Message-ID: <alpine.DEB.2.20.1902261648430.24327@uplift.swm.pp.se>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org> <bbd8b761-403a-5b3f-3f04-dc3bfdea116e@foobar.org> <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org> <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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KFiTtDDQ96-T81snwKyvDcakmkk>
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: Tue, 26 Feb 2019 15:53:05 -0000

On Tue, 26 Feb 2019, Bernie Volz (volz) wrote:

> How does a Reconfigure play into the ISP-router recovering its state?
>
> Reconfigure is between the client HGW and the DHCP server. The DHCP 
> server can issue a Reconfigure to the HGW (obviously communication needs 
> to be restored at the ISP-router - hence the bulk leasequery).
>
> Note also that there are two ways for the DHCP server to deliver the 
> Reconfigure to the client - one is to unicast to the client directly, 
> the other is to relay it (this requires the server to retain the 
> Relay-Reply (or Relay-Forw)). Our server supports both methods - the 
> operator can specify when they initiate the Reconfigure.

Does the bulk leasequery really put back all needed state in the relay? So 
there is nothing needed to have the HGW do anything?

For a different scenario, in the sense of "the customer was moved to a 
different BNG" so there is now no state on the new router for this 
customer (but the HGW doesn't know), how is DHCP reconfigure done?

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

v2.23.0 | Report a Bug | By Email