IETF Logo Mail Archive

Re: [v6ops] Updating RFC 7084 - alternate logic

Ole Troan <otroan@employees.org> Fri, 02 December 2022 14:30 UTC

Return-Path: <otroan@employees.org>
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 41903C14F6E5 for <v6ops@ietfa.amsl.com>; Fri, 2 Dec 2022 06:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.205
X-Spam-Level:
X-Spam-Status: No, score=-1.205 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
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 i0gM88TwqBNv for <v6ops@ietfa.amsl.com>; Fri, 2 Dec 2022 06:30:37 -0800 (PST)
Received: from vesa03.kjsl.com (vesa03.kjsl.com [IPv6:2001:4830:c170::91]) (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 0194FC14F728 for <v6ops@ietf.org>; Fri, 2 Dec 2022 06:30:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=employees.org; i=@employees.org; q=dns/txt; s=vesa202009; t=1669991437; x=1701527437; h=content-transfer-encoding:from:mime-version:subject:date: message-id:references:cc:in-reply-to:to; bh=BDc97vJMrPGxO8e7Zr+XSS8k+Jcc6CB3RNl/A0ckfMQ=; b=H9eq+7CV/GiFq5gYN4qIQ6HeSHniP/KOR3WobD3UJoxneMuODb3gZYyL hU+ztceym2avpzQA21zzz0YAL3HuWn0P+fU8QAKxww/zEQ7eOCH40MTfu Cggib8tQHIYV3tevlvHuUFNEbNYQ9rPh4ufxRrcDnfzbhMmAf5UGpSlVp TIJZv7jAY6O5N21CARsT7N6kVJkG1hFIgkDGcgegw14gcZy1zPlkPNs9z uQkc+sC5pJtxwF1W1ZW4evDy+flmC+VXfszHhlIoIkHlYXbXb0hGO7KgH OIdreINcAE44nuYD6oysgg3c0lAqhrP0kQdl7utzF2yy5VxCG3kFkm3sZ Q==;
Received: from clarinet.employees.org ([IPv6:2607:7c80:54:3::74]) by vesa03.kjsl.com with ESMTP; 02 Dec 2022 14:30:34 +0000
Received: from smtpclient.apple (unknown [IPv6:2a02:2121:655:57f2:20cb:cbb9:d027:51b9]) (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 clarinet.employees.org (Postfix) with ESMTPSA id D2EC14E11A5E; Fri, 2 Dec 2022 14:30:33 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-567C58A3-B24E-408F-845B-ECEAE9490051"
Content-Transfer-Encoding: 7bit
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Fri, 02 Dec 2022 15:30:21 +0100
Message-Id: <E86D5EED-2643-4211-9C51-1B23B6A452E9@employees.org>
References: <CAPt1N1=KuQOuHMChoGQT11+sWcSHbXwhN4EJ6b4wNmc0YcPYiA@mail.gmail.com>
Cc: Ole Troan <otroan=40employees.org@dmarc.ietf.org>, IPv6 Operations <v6ops@ietf.org>
In-Reply-To: <CAPt1N1=KuQOuHMChoGQT11+sWcSHbXwhN4EJ6b4wNmc0YcPYiA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: iPhone Mail (20B101)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/VTR1Gk4zQPHgrWr4t73ZT7uGpk8>
Subject: Re: [v6ops] Updating RFC 7084 - alternate logic
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: Fri, 02 Dec 2022 14:30:41 -0000

I did appreciate your spanking trees too!

O. 

On 2 Dec 2022, at 15:25, Ted Lemon <mellon@fugue.com> wrote:


Sorry, autocorrect was “helping”. I meant non-tree topologies. :)

Op vr 2 dec. 2022 om 09:23 schreef Ted Lemon <mellon@fugue.com>
Op vr 2 dec. 2022 om 08:48 schreef Ole Troan <otroan=40employees.org@dmarc.ietf.org>,
Regarding the comment below. If two routers are attached to the same link, they will both request a prefix for the link. That’s not what you want.

We have a solution for this for stub router which would work generally. 

Regarding relaying, as you say that will work when there are multiple upstream routers. You just need to know where to relay to. Don’t think we can assume site-wide multicast. 

In order for relay to be an option, the router that would act as a relay must already have done DHCPv6 pd to number the link to which the subsidiary requesting router is attached. So there is no need for site-wide multicast here. 

Regarding multihoming. MPMH is unlikely to ever work well, so I am also (unhappily) accepting to drop that. 

Not ready to give up on this yet, but I agree that it is out of scope. 

BTW, regarding Jon-tree topologies, from the perspective of a requesting router, there will always be a direct path to the delegating router. If there are two paths, the same prefix will be assigned over both paths. I think this means that a loop can’t happen and you don’t need spanking tree, but we’d need to think about it. Again out of scope for this document, though—this document is about address allocation, not routing. 
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email