IETF Logo Mail Archive

Re: [v6ops] Updating RFC 7084 - alternate logic

Ted Lemon <mellon@fugue.com> Fri, 02 December 2022 14:23 UTC

Return-Path: <mellon@fugue.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 7D8A0C14F740 for <v6ops@ietfa.amsl.com>; Fri, 2 Dec 2022 06:23:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 rPmp4BRHg58T for <v6ops@ietfa.amsl.com>; Fri, 2 Dec 2022 06:23:21 -0800 (PST)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 BC6CDC14F6E5 for <v6ops@ietf.org>; Fri, 2 Dec 2022 06:23:20 -0800 (PST)
Received: by mail-qv1-xf32.google.com with SMTP id s14so3464472qvo.11 for <v6ops@ietf.org>; Fri, 02 Dec 2022 06:23:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=co54ZZMmjPpo6n+hMrCB4l7X6nEpCPBXpAiMwyG8eXo=; b=tr55vyIqrzjdb71dFgLMJNY4lKI4f8paX/3XW9n2C4kkwgH94q01pP9tM/Sva1qLXd YwzoJ7abNFYe4Mjw/tqAoPEFDCm32lJxnfnFIsXW78yymyiaNI5ClETFDBdboh4F7m5r dYYocNMwGXd+e8v014URtq5wS2grU/UQ5+RZgbQ64yqUvDAJPJDWjDZbIC51eJ4oebJP VtvuCTCsLh4q7oqZG1anvK21noQ7BQO0rc4FhaZDwrbQIhsVjRLROdCdoHXsSDHG9gQ/ pcr5ibESA9knJv4EdX050Hj2JOkq/GYGejRjZHe24uSTDIcYvWLnGDY2pt2sgMU1PM2q Bv3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=co54ZZMmjPpo6n+hMrCB4l7X6nEpCPBXpAiMwyG8eXo=; b=8H5pz2pYGwhjvoHyayL9+LrRRo+oGGndzlpj4kjfz5mj/hmg9UiC+gZOnCoVCglkTp av8LQ0e3rxxQDP0H6W7ZyG6LLt6juOBFKCmE6xDAzCpM4vkQc7ZuitzJKgOyguhyOFS7 qdxHsXeEE95vR9OFWilo30AABLXwW1VVs2nyZBoDJRN9k7KjEh0ZfNBan9AYg2LdSbLW zyoBA2nRKSsVw7Ng379d47h+h40XnkifXrHKODl+wL83qJFseDzUwlMtUuEO7XiDjcFi Al2R9TWHev5mqRSZ/1NhWrqzOuesOZOtLdT1EGIkoFuaxPi3VeBLztGR2HPHutGXgosv WUZg==
X-Gm-Message-State: ANoB5pmRemPIInT++W20/kVTCCWN5BslfBkQ2FKI0ZkHLxLIxDyQpwS6 vWWMAYI/ZoFYTlKY5FGUVgHjC/aNeI6sTRKI1euPww==
X-Google-Smtp-Source: AA0mqf5zY9+EZUi7Hzn1/Dz+Zts11wNAapydLtSDaNFsyLgg/+nM5XDJ0DdehZAJk6oo5ey9ZfSUilwbCsdj3WzrZN8=
X-Received: by 2002:a05:6214:5c44:b0:4c6:c037:cc37 with SMTP id lz4-20020a0562145c4400b004c6c037cc37mr44849746qvb.101.1669990999943; Fri, 02 Dec 2022 06:23:19 -0800 (PST)
MIME-Version: 1.0
References: <CAJgLMKs1w23rGOFp4YssCJzQypwEn5=jF-LZ1embJrm0_d1N3g@mail.gmail.com> <B5C25164-3EB1-4F90-9E54-E21F64680654@employees.org>
In-Reply-To: <B5C25164-3EB1-4F90-9E54-E21F64680654@employees.org>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 02 Dec 2022 09:23:08 -0500
Message-ID: <CAPt1N1nq_jO3ZGRxGFy7R+EKu9Hgga2JnBWS_wSAeHCLvRbSAA@mail.gmail.com>
To: Ole Troan <otroan=40employees.org@dmarc.ietf.org>
Cc: IPv6 Operations <v6ops@ietf.org>, Timothy Winters <tim@qacafe.com>
Content-Type: multipart/alternative; boundary="0000000000005493a105eed914c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/CrkA559CISX9CpvKbNx1uDpyg-k>
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:23:22 -0000

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.

>

v2.23.0 | Report a Bug | By Email