Re: [v6ops] ULA precedence [Thoughts about wider operational input]

Ted Lemon <mellon@fugue.com> Mon, 25 April 2022 11:44 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 C7BD23A0BF0 for <v6ops@ietfa.amsl.com>; Mon, 25 Apr 2022 04:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjhUS3toGOYE for <v6ops@ietfa.amsl.com>; Mon, 25 Apr 2022 04:44:50 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558BF3A0BFC for <v6ops@ietf.org>; Mon, 25 Apr 2022 04:44:50 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id w27-20020a056830061b00b00604cde931a0so10595174oti.2 for <v6ops@ietf.org>; Mon, 25 Apr 2022 04:44:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F1lvB83eML5IDSonWVN/lxP2FSYuCqOt1IPmJywm2EU=; b=BCwJvn879xRGcdXUv9XRc0CLAPhSoOcRA962TOkehySinuehB8U8RwN218puxEXkVX 0AT4P0zyDz5B3u8+MNfzJcUCq7P/mKJIiwU/uBzyb97DKr00TlKHISlra8E2qhnEJ8Ns lGhuIJ9afqu1jv9skeEH8/mKLIhFOteahYjr/Z8famzbTDukVQ2bBhI6bJMAFU1GjUDV zqs6K9Fpa+wlo9u6mZ7wM38JsCK35BTSE4w5W1j8Nh0Xcvvx3SBEhjZCqv41D0zH5ctS vV6Zl9hLxnYmHw4z1RPTe5gZQFX4fTdi6F6zgzVWNpfE45+N7WmFQYjW3qOBb6WneLST wHQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F1lvB83eML5IDSonWVN/lxP2FSYuCqOt1IPmJywm2EU=; b=6ZJf5gU9vaLesHl1dj2VNsbObbrkaOw61j/d02URq3T1RdjF+wnZ6iPf5Kn9s5Dfo3 Rm8H5tXIOnggRMVF7rqTpWiS+8c10Vv7XcIMnC1VIEjEgcGfhL6FimWueYcovZB6qygL jhIq60JDhOZ0pg551WdVJvRkmRR3TATyx1bjGoFzaAVByRCJWmMt/MlK9uAb343hjJbs bUX+MMc4yulu+kPHt7zmdNozOn4JhU3VgLLbcO3+Jwndro28lHRKYrjOiHG+SPjNiuul ZRwgDTD4Qq5x8DPWbidesNIeNkjr5cc5AIbeVkys6lXe+A7RUFiJyoEZGoBFPwCZCxhY oK/w==
X-Gm-Message-State: AOAM530yp8PK4o7dm5Fo60nF25swtip1hYZqzcqrgV+doig5Vmjsaluz LQnp5saLDmydV3gfMzOYVVPXq0rz7wh87I9QXb3xPQ==
X-Google-Smtp-Source: ABdhPJwcRSsadIbm5sKN7kuVZJlenx8XtQ5p3EQq5FBBthrOZLHC7o2lflQVbpq42TSL9yN2a8DHdDz7I8LoYIvoxBw=
X-Received: by 2002:a05:6830:1e34:b0:605:5ab0:945b with SMTP id t20-20020a0568301e3400b006055ab0945bmr6180994otr.285.1650887088904; Mon, 25 Apr 2022 04:44:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAM5+tA8WvjvWirxqE6kQ9LQAG0NcpWyCLGVooB=G7gZ9ETb2zQ@mail.gmail.com> <20220424172743.GA218999@fg-networking.de> <CAKD1Yr1v0Tkh+pWD-ts=PL3gZf7Qj6OHW6Cuvj8iGcSSMibjew@mail.gmail.com> <20220425100310.GF67548@fg-networking.de>
In-Reply-To: <20220425100310.GF67548@fg-networking.de>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 25 Apr 2022 07:44:13 -0400
Message-ID: <CAPt1N1=XedJ7tY9pKDS3LvDMak6iPsK9fA=oF7Z0KkmGcA6-_A@mail.gmail.com>
To: Erik Auerswald <auerswald@fg-networking.de>
Cc: Lorenzo Colitti <lorenzo@google.com>, v6ops list <v6ops@ietf.org>, 6man list <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007fb15405dd791a5b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/iX8XjvA7GyJLFir4fzbIXN-gpJs>
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 25 Apr 2022 11:44:55 -0000

On Apr 25, 2022, at 06:03, Erik Auerswald <auerswald@fg-networking.de>
wrote:

And all that would probably not preclude constructing a different
scenario where choosing GUA over ULA as source address would break
connectivity.


The question is not what possible scenarios are there, but what scenarios
do we want to address with default behavior versus what scenarios can we
only address with managed behavior. So e.g. not using longest-match for
ULAs with different global identifiers sounds like a good default behavior,
but obviously will break in some scenarios; in these scenarios, clearly we
need support for configuring source address selection (which we already
know how to do). Preferring GUA source address over ULA makes sense by
default, I think, even though it is not always going to be the right thing
to do.

Thus I would rather suggest to consider if making tracking which
gateways advertised which prefixes mandatory would be a better
approach.


That's nice, and again would probably produce better default behavior. But
I suspect it doesn't solve as many problems as you're hoping it will. E.g.
what happens if the link you're connected to is one hop away from the link
to which both of your upstream providers are connected? Now you have one
router advertising everything, so this doesn't help.