Re: [v6ops] [Lsr] New draft: carrying/renumbering assigned prefixes in IS-IS/OSPFv3 (lsr-v6ops-pd-aargh-00)
Acee Lindem <acee.ietf@gmail.com> Sun, 12 November 2023 17:05 UTC
Return-Path: <acee.ietf@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 AC778C17DBF1; Sun, 12 Nov 2023 09:05:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTWqPLJiux7T; Sun, 12 Nov 2023 09:05:02 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CA5C17DBF0; Sun, 12 Nov 2023 09:05:02 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id af79cd13be357-778a6c440faso188215985a.3; Sun, 12 Nov 2023 09:05:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699808701; x=1700413501; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QRYMHBIY8lOfZCvCDfqy7yyGF/NUW9RO2Dt3VwAICiU=; b=LEKUyc/O/KiWW5/oaYvv4WeQqR6OScRo/wSKJxCBf4r2uL0J8eDk/rdPNEAltBdtDm QrNMg2FJwxvr5WTmCL51Lzv8Oysf5zteBgMU313JWYsrLih71DHuM/HJ8v5EvZA2BeGR NaB3MQ113W1NwjCGd/M3BadNPnvMrd3mq+iA4kt7F6wXMtpQ4JaE+wC9jBciEmDWFErG ci1J3WDc9oYOAmvU4EhttQ7BAgbSW3AuLbQc/350l6omSfNXNaeu+KUsCSMzV9NhKstd d+s+IFu83KeGtpwGqCGTYtOy3HGvG0MPO3eSTiJF5zZwoRYlUufxkhID8tYADpfDDO73 rbfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699808701; x=1700413501; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QRYMHBIY8lOfZCvCDfqy7yyGF/NUW9RO2Dt3VwAICiU=; b=gbJ/tqeIvNtaqthGh3bXtMeMTNhySTg+ck6TiNUGZZJslaBHzcYrDm9QZjejtYTSWM 6zdOvH3IJjj1Nklf0OUvcD/ShoNGMWptYG33WazFA5JQaKv0dkz2+uODAcLV0PnC+d44 jSZ1dfAYvUyr4k3HfC17bWUMg7eUqBHETlp5wG7pQ3HV5Rm+QlpaPrZttGdiklSQmfim yPB+N6EIuRSbDIKJaD/F29QoUKuSPHv7rfCrKTOqZmVWVdMDxM1+968cZyMG2/CLkqtl USxPZVoZ1lsQGoFg3qjQ+EZIYq/883ryle61Hdz8s2mVCV9wVjwuJEqfzjACG1e//Vfc Pikg==
X-Gm-Message-State: AOJu0YxNiFdsGKPDyb0EidQrJMnEm74lB47o9g6kQ7NE/BdrOcgiJN4/ vVgZZNTCbbeaZwRCdmLdpK0t6lrKbJQ=
X-Google-Smtp-Source: AGHT+IGwRlHObAqX9UTc0K6UrMXHSFTQubafZfOK7U9KQDAozaTQ8kmVRz7sqy7ZclkmR13C42Xn7A==
X-Received: by 2002:a05:620a:2488:b0:77a:4466:354c with SMTP id i8-20020a05620a248800b0077a4466354cmr4413200qkn.49.1699808701090; Sun, 12 Nov 2023 09:05:01 -0800 (PST)
Received: from smtpclient.apple ([2605:a601:91bb:5200:8cd9:ec25:b7da:3eab]) by smtp.gmail.com with ESMTPSA id x3-20020a05620a0b4300b0076cda7eab11sm1241065qkg.133.2023.11.12.09.05.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2023 09:05:00 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Acee Lindem <acee.ietf@gmail.com>
In-Reply-To: <ZUee2yOWQ4w3sSi1@eidolon.nox.tf>
Date: Sun, 12 Nov 2023 12:04:50 -0500
Cc: lsr <lsr@ietf.org>, v6ops <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <42859BB6-AD5D-47B3-88C3-89F6F0FC8FDC@gmail.com>
References: <169040811486.3424.8754095352967452988@ietfa.amsl.com> <ZMGZSJ1X9IU0Zek8@eidolon.nox.tf> <C08DD447-7A64-4364-AE8E-ABF8E35F3096@gmail.com> <ZUee2yOWQ4w3sSi1@eidolon.nox.tf>
To: David 'equinox' Lamparter <equinox@diac24.net>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/QbY2cgc1KOHZP3XXqrmBG6OG30Q>
Subject: Re: [v6ops] [Lsr] New draft: carrying/renumbering assigned prefixes in IS-IS/OSPFv3 (lsr-v6ops-pd-aargh-00)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 12 Nov 2023 17:05:02 -0000
Hi David, > On Nov 5, 2023, at 8:55 AM, David 'equinox' Lamparter <equinox@diac24.net> wrote: > > On Sat, Nov 04, 2023 at 09:33:57PM -0400, Acee Lindem wrote: >> I thought that DHCPv6 Prefix Delegation (PD) could have multiple >> levels of delegation and that mechanism alone could be used for >> assignment within a domain? I must admit that it has been a very long >> time since the home net WG discussions. > > It can, but using it that way essentially forces you into picking an > "upstream" interface on each router and building a spanning tree that > the assignment travels down on. It's just running the same protocol > up- & downstream as server and client, not some actual "levels" feature > in the protocol. > > Unless I'm misremembering (yeah, long time...) there was consensus that > hierarchical DHCPv6-PD is not desirable for homenet; if a network > warrants using OSPF or IS-IS, hierarchical PD is going to be even less > desirable. I agree that the partitioning of the PD prefix is not going to be correct in anything but a trivial network. If we were to distribute it in OSPFv3 we would need logic outside the protocol to partition the PD prefix as well. As we discussed offline, this could be configuration that statically assigns prefixes independent of the first 64 bits of the prefix received from the upstream providers. In any case, your next step to test the waters to see if users actually want this. Thanks, Acee > > > Cheers, > -equi/David
- [v6ops] New draft: carrying/renumbering assigned … David 'equinox' Lamparter
- Re: [v6ops] [Lsr] New draft: carrying/renumbering… Acee Lindem
- Re: [v6ops] [Lsr] New draft: carrying/renumbering… David 'equinox' Lamparter
- Re: [v6ops] [Lsr] New draft: carrying/renumbering… Acee Lindem