IETF Logo Mail Archive

Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

Robert Raszuk <robert@raszuk.net> Fri, 26 August 2022 22:48 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71782C14F747 for <idr@ietfa.amsl.com>; Fri, 26 Aug 2022 15:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 cbbkhCueY9qU for <idr@ietfa.amsl.com>; Fri, 26 Aug 2022 15:48:27 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 8BF2CC14F72A for <idr@ietf.org>; Fri, 26 Aug 2022 15:48:27 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id p16so2534403ejb.9 for <idr@ietf.org>; Fri, 26 Aug 2022 15:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=qIz6bQEP4e2inlPE2TdeMD9u9rK69/eEYxwTU+hHcD8=; b=EazelLqv+wNa2SUgkl4G/mqTpnHCXQQH5tWZ7cd4sanjEm7gfX8zFAwjp1Iw4MPKQB cWwkT6zEDWUsX7qEkyR3DEQp+pFvMHWrxTIlgR4hj/rDNnjX9/+w/BWhtWW3BuNn213b nHA0o+wGAjGv6HsX8DCApBEI24ZkC/wqUSd8Vib6kB50I/bMPR52CJ+fs64CDpaa+mUY 9SZYbeQAKuoeIwL+yXlh0Yo+55vLXgOC4AY8yGP5YtxmJY6RwnhNfbmkV/lnwmjS5RBf vSOot5UcpLKDM18HTzM8C55AoizQJBBvy9VK57fd072gaZAtj7Fn4xPX4WUhuVEqegi9 0AUQ==
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; bh=qIz6bQEP4e2inlPE2TdeMD9u9rK69/eEYxwTU+hHcD8=; b=cCf6BAS582Okfhy1iSS2BlqfcfhWf0wVGV2pgEhEDQcGL823NRNzkdRH1sqix10XBg vlPs0DvPiPflKuBIT+LafoGNOzCw9YGTx5eSdiovhT/H/8OSg9pZEj55wi4gZDZxEDQ+ FoIBd3k9lKjGvhJ8y6YqVD7T0h7MI3pblJ47eae7nm7sevJSFht4wZajzhqUYkeJMo/s HRzgTB+8GZ11xh6hWDyde/9dNMAd3WjVIA4qOBmSqO1r6EQcLb0VD5niiAStvuMpK6Zr UWDGPKDqVriy32H5hMxBpgOwDKUzBBcQmerS5U7FBhgcUyLKitKc7/zTcQ0YHmIFNbSF I8vg==
X-Gm-Message-State: ACgBeo1Cxazt6zO8XrinR8L2by4o8GUhx23BO13iEahSGG8awnnNPEaQ n4JDyPG0iA6/TvmZXdU8qnxhtfcIKBXQ/aWrpVz4tx3XeX5EYQ==
X-Google-Smtp-Source: AA6agR7qzg52EXmfC+ux+XXO4dbs8RplWHwqU5CaFQVFxwbQezNraqkjFIViixZ/pn7Y4Eg/enoxljuN5Jrx4SjPWBo=
X-Received: by 2002:a17:907:97d5:b0:730:9eac:d965 with SMTP id js21-20020a17090797d500b007309eacd965mr6626942ejc.353.1661554105582; Fri, 26 Aug 2022 15:48:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAOj+MMELVifgg4Yj38kyncDGYzS5fJG-43_kRc7YLwJiTPANUA@mail.gmail.com> <23D1B383-F794-402E-AB1B-D966F8F3375B@tsinghua.org.cn>
In-Reply-To: <23D1B383-F794-402E-AB1B-D966F8F3375B@tsinghua.org.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 27 Aug 2022 00:48:14 +0200
Message-ID: <CAOj+MMGs9gU=xC0UG4Xaiv5feo2U6VFXkdAxmk6arN_bxe_mSg@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "idr@ietf. org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="0000000000003d1e6f05e72cb65f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/h1IUh2ZrO5B0cvX7Cho46Kv4Y_k>
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2022 22:48:31 -0000

> I admit there will be no single solution for one problem.
>

The role of IETF is to standardize a single solution to real problems. At
least we should aim for that.

Your problem description is this:  *"rogue PE"*

Well to me this is not sufficiently precise to convince anyone that there
is a problem to start with. At least I am happy to see that you are no
longer stating that the problem you are trying to protect from is "rogue
CE" (as clearly PE-CE prefix limit will effectively mitigate it
at its source).

Bottom line is this - if we assume that any PE can arbitrarily misbehave
and inject bogus stuff in the routing control plane then we have a much
larger problem. And IMO the right solution to such a problem would be to
take such "rogue PE" out of the network ASAP. Not to cherry pick who's VPN
to cut first, second, third on RRs in the path.

Rgs,
R.

v2.23.0 | Report a Bug | By Email