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))

Ted Lemon <> Wed, 13 November 2019 15:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 529E312023E for <>; Wed, 13 Nov 2019 07:20:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8yE95TSEf3O6 for <>; Wed, 13 Nov 2019 07:20:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F80F12002E for <>; Wed, 13 Nov 2019 07:20:31 -0800 (PST)
Received: by with SMTP id i17so2982572qtq.1 for <>; Wed, 13 Nov 2019 07:20:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GWhJMV203met4jq40BGXG5jyRNQdIxLnf+tnqZZqw6A=; b=ccJ/jxWdpN5Ci28aeki+En8bhLCZS/MePUwufSSFoRSVIBYI6GimLoK91lxkpR1SA2 HbvqwdPVHV2QDHeRG506wuCwSp/oo39xYn5zDtN6V4M8tDW94+g5gAySO7Vy/isVXujQ LwPDNRnpVrUsBm7o4W6G4+lroRsvNT4/G3nzredSlR60C3ikUP5niWrLZw+jUczLF4Z/ 2vaX1aYjdBItA9/XrcyHvuDT1ZV62ZtoKMdZRj4oBTdcyj4XLCIUeyTYZ9E9Pf6BOq7k 8gYQiBHt6Ypsu1NgUgNICzWBymOixBU2vehVKpOuYvFH6k0I3Kcfo1igZVD37ow8OMCP 8x9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GWhJMV203met4jq40BGXG5jyRNQdIxLnf+tnqZZqw6A=; b=eBNuQ14zUuKW/c1+2qG/bebSkya/pCze6kihatJ6N1orftJKb/CBKHmk59ozLpg8uw yld48IXedMwq6DiSXEdct6D6IO/J+bCKgsrKXbPBxLXT0nVzTP0RqK/W5/RbEdjhi0jb gfmvfY8f4uUupu5T2bPoF4kGTqd5P3PrrAXmwFOe1osl1LaU2jeuTaLSvzaMZOnu1eqW InvFUaEBqofLuIR7wIze9kiAMS3sYpIWh3f3VyyXF2M0eiB6NYRk7PsUygHlOfenDre/ G6To0LyyTE29723JnBjHs8TW5PbkzNeCmDo4gutuXRE37HxprL1+Do6weOYMlmu+7pRS +OHw==
X-Gm-Message-State: APjAAAXzhBeQVQtdcPJhAJM7fezLOg6F8746OJfi708G32zDDNfaHyCi k29Sh1nSQjrz2OdZoQsO1AORk7rCoVODhA==
X-Google-Smtp-Source: APXvYqzClVHnTPFolRy6nzxDQQxnCbrSXXnqMsmVTZwT9liPB1LTOv165qyqecZz4vidIWrqd2+ocQ==
X-Received: by 2002:aed:241c:: with SMTP id r28mr3191804qtc.148.1573658430503; Wed, 13 Nov 2019 07:20:30 -0800 (PST)
Received: from ?IPv6:2601:18b:300:36ee:900d:f981:2ce3:f5f8? ([2601:18b:300:36ee:900d:f981:2ce3:f5f8]) by with ESMTPSA id f21sm1380170qte.36.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 07:20:29 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F63AA54-CE61-465C-945C-9A3068DDAE64"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Wed, 13 Nov 2019 10:20:25 -0500
In-Reply-To: <>
Cc: v6ops list <>
To: Richard Patterson <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
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-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2019 15:20:33 -0000

On Nov 13, 2019, at 5:50 AM, Richard Patterson <> wrote:
> A different BNG vendor of ours however, doesn't have this configurable hold time concept; once the Valid LIfetime expires, the MAC+DUID binding to the PD is cleared.
> They do have setting to retain the MAC+DUID->PD lease binding indefinitely, however they didn't satisfactorily answer my question about cleanup if these bindings are exhausted (CPEs that use dynamic DUID values perhaps?  Even though even the DUID-LLT method is *supposed* to be stable).

FWIW, I don’t think there’s anything wrong with this.   The network is not obliged to remember that you had a prefix after the valid lifetime of the prefix (the promise you made) has expired.   I know that you’ve heard a few people here say that you should keep this prefix for the customer pretty much forever, but I don’t think that’s the consensus.   If you keep it until the valid lifetime has expired, I think you have kept your promise.