Re: [Sidrops] Which 8210-bis error code should be used?

Tony Tauber <ttauber@1-4-5.net> Fri, 02 June 2023 17:54 UTC

Return-Path: <ttauber@1-4-5.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E0C14CF13 for <sidrops@ietfa.amsl.com>; Fri, 2 Jun 2023 10:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 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_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=1-4-5-net.20221208.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 v7efmSPG1T_r for <sidrops@ietfa.amsl.com>; Fri, 2 Jun 2023 10:54:16 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 29C6FC14CF05 for <sidrops@ietf.org>; Fri, 2 Jun 2023 10:54:15 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-53f70f7c2d2so1432478a12.3 for <sidrops@ietf.org>; Fri, 02 Jun 2023 10:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1-4-5-net.20221208.gappssmtp.com; s=20221208; t=1685728455; x=1688320455; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mPcmkTfCf2OZnwZqJ6J+6yRnUrcX1dnWDFdaAZFKvG4=; b=hzMxPmTewejbljsY5ELPP2NO5741EzibutX1+3dMwd8N98eJ2sbN5weMTOF6EohuMW e7k1EBb9esjrDmlPY4Uw3AsBXzO8UB70BupCbBmCga/FT8a5c7iwZzkMfNZNdbgNqGOi Syz1Zq2vnUfY0Lu/JSpm1fhibIy7l1p27dkOhxXhOSow97oiSBNemmd1uqhKQYQlZRMk 6UYcNE/AVX0DJseK3kBGu4xePWgagrhRTupJKkPRejHW/7Ch9G6Swrj/hxM6QLqd3hmF raZD/ptQ3agZ+XFZLHvmnH4CNrOO6Y2Qx8pWHQko+djZhxe/mgBwqSPrJfoDM03ktlNS 7ovQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685728455; x=1688320455; 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=mPcmkTfCf2OZnwZqJ6J+6yRnUrcX1dnWDFdaAZFKvG4=; b=bXR3Gs2jC3xRYB77BpNLjpbHphd9jTOpjrRKRXyYatIsnGFrEgS9lsM3R8EFpsi24C jxQ5lvFeSdF8gXdU9Aqr/0GLMaIXFo+3gc5eQtFFk8WydP5tWnzjhERiTLiiJe8dzPuo nlRBv1o++G4Wc3XSdt+nCBBEGlbxvyZQA1PaJpZe4RDEjy9Rlq1O9+K072GTAhhN2d7+ J7hb2P5I+adxmwZTt50zXHVfKtgBn14NXhnUpLx0YC1MfnSd12AUkwj1QM6njQSzxD4/ 5Evl0iFNPhWYyXBdx5g3wpMaQ1vO6nKve9gArtIXGwneWzDM/s0Yom+yaMuBqkaIU5CJ uYrw==
X-Gm-Message-State: AC+VfDw2Oj0CrCivN6ldK8adkd6b5/jefgekKRhiLZbAaiaNkvXk91Tl SJn9A6q9zKwjLiCVWDSn1LaXceaUH0ndY3wNe1FPyWyJTYRU41oE
X-Google-Smtp-Source: ACHHUZ4bcZJjBOhhEppR0a1hn/K4tmcbgHd2RpIi68B7E8fW6qBW1zETrGXAoTp4Iv3rIHUH4NqUOiweYcEkxOh6QBs=
X-Received: by 2002:a17:90a:5212:b0:256:6c79:df6c with SMTP id v18-20020a17090a521200b002566c79df6cmr550239pjh.27.1685728455102; Fri, 02 Jun 2023 10:54:15 -0700 (PDT)
MIME-Version: 1.0
References: <SA1PR09MB8142523FA03AC4EA6E0E014E847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB814235BE0566A5C6935CF5B184439@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB814231707524646D651B69B884439@SA1PR09MB8142.namprd09.prod.outlook.com> <ZGs5bFRjPLnyL2Jd@diehard.n-r-g.com> <25708.55138.924074.242182@hrabosky.cbbtier3.att.net> <ZG2Vobyxl/gPEfCU@diehard.n-r-g.com> <20230524100558.452d4caf@smaug.local.partim.org> <ZG3bN1p4EzSn4XIS@diehard.n-r-g.com> <CAMFGGcDCpQDYNbYKLEp+iT4rx_FNLoWkdNmET8tH1JdQpgi5XQ@mail.gmail.com> <m2v8ghzypr.wl-randy@psg.com> <20230524152102.5fdfd8f0@glaurung.nlnetlabs.nl> <A40A6EDF-7DF6-4085-9274-CB76122DB1D9@nlnetlabs.nl> <25720.46861.482040.787946@hrabosky.cbbtier3.att.net>
In-Reply-To: <25720.46861.482040.787946@hrabosky.cbbtier3.att.net>
From: Tony Tauber <ttauber@1-4-5.net>
Date: Fri, 02 Jun 2023 13:54:04 -0400
Message-ID: <CAGQUKcc2ABDQ_CQ_uObqN=jD=BDStZ-+JHWj9YRJLxamwt9U_Q@mail.gmail.com>
To: Jay Borkenhagen <jayb@braeburn.org>
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c12b9c05fd293df4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Xiav_iBqZsmfvVHGVqBg9sbJB1k>
Subject: Re: [Sidrops] Which 8210-bis error code should be used?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jun 2023 17:54:16 -0000

I agree with this approach.


If people have chosen the path of trying to support non-congruent AS
topologies with different address families, that's on them and we shouldn't
complicate the standards to those edge cases and the people who've opted
such can deal with the residual risk they may encounter through such
choices.

Tony

On Thu, Jun 1, 2023 at 11:20 AM Jay Borkenhagen <jayb@braeburn.org> wrote:

> On 24-May-2023, Tim Bruijnzeels writes:
>  > I understand that there are differences. But, is it a big enough
> problem if a provider that is only used for one AFI, is also authorised for
> the other? Enough so to warrant the complexity in the profile and
> validation?
>  >
>
> I agree with the others in this thread who have argued that the
> complications required by making ASPA be AFI-aware are too steep a
> price to pay.
>
> Let's keep things simple and remove afiLimit.  The ASPA for any AS
> with non-congruent v4 and v6 provider sets should simply list the
> union of those two sets.  Very little leak detection / prevention
> capability will be lost in the process.
>
> Thanks.
>
>                                                 Jay B.
>
>