[Idr] Re: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt

Robert Raszuk <robert@raszuk.net> Fri, 08 November 2024 11:01 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 A19F4C1D4A99 for <idr@ietfa.amsl.com>; Fri, 8 Nov 2024 03:01:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 sAMA6szd7yI6 for <idr@ietfa.amsl.com>; Fri, 8 Nov 2024 03:01:53 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B88C1D52EA for <idr@ietf.org>; Fri, 8 Nov 2024 03:01:53 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5c9c28c1ecbso2514058a12.0 for <idr@ietf.org>; Fri, 08 Nov 2024 03:01:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1731063712; x=1731668512; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UUK0/veVAgYk6uA6JFo7BhmHWJy5kkwkk6VzKaTvXKs=; b=T9ByLbHN71MN1fyqwnVUqKW6uU4dfml8wRzQ8HDb+JALTovHtCYCbfR7j5EBtJaM1e kQidu47f/cSbbD1V2TLza/qVTuPyW5c1x8+FGTX4VrIWitfeTBRhJWkpz9sFP/eJ+L2j dHBTrlA69rih2ZhtDT2r0ZLy97qgjbfpbYLlBBQR/KZZvUVxCDP9EtvpeSH9RhQDZRTv skaae53J814dIFYkIm3AGBpXW6EfNQCgMJsHSmjBtqPp17kStH98ZaCyhiWh36n8bO+B E4zy14BFtFkwOU2o0/YYt9xeM/jgF/xqlMWf7uE0rl+ZXN+KSqTQflm3YqMROWCZ6YcQ 88dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731063712; x=1731668512; 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=UUK0/veVAgYk6uA6JFo7BhmHWJy5kkwkk6VzKaTvXKs=; b=vLrCLaOb70UrPP1/+jRNKZtzeOoEk0eJxUzeBJ32EEICuYiUR1b6W+hUUlMENOi2gZ zZDiTW6zsQn3FLLKmzaaQ2aKPyDpPQ392H53eORsNtlSGJeh0AZoEWq24OUgh0u3U7Sb jPXPUR0IL9leuCE+Z644LTVTTuVTWQfcSQAYA2yI45AsTRnK9V5Mob4Uh42/rMG9QjQW ty8tmmy9qkBrGmHDh/ZW1ztkJzjk6sxjlij3utIIxDyKRVkVPRJLy5vQPkKQhRYqQFJN rHQEBvrOYzH+UMEwRk+8Yg1XH8G6IUv4zCt1RNwte9U8+gCZhkw+YZHu1BnPIh7CZc8t qYYw==
X-Forwarded-Encrypted: i=1; AJvYcCUfkhWEfFLfRiEZatF/KXyn/9lsAo8uEwp337+wovM8k5J20wMYQEunIC446usILoV/RTc=@ietf.org
X-Gm-Message-State: AOJu0Yzx5lnhGzjkwTgDsjUS7LfGCRpYK7zTjRkBiD6IOIohXlGlvfjY E+CG68X7kKxYZmqVtgKb1NZTe8ng/HI9FIvbQhvcu5sEeAugGE//mdaU0Px/dzNsL4pPjjpMvNX x+8YQgf2zqTUMMgI2pMVHZBJYKcoSct+Bzvk19meKCbOVMesWpKQ=
X-Google-Smtp-Source: AGHT+IGz4YaCutVTzCkYc7HRq1axZHcv/0OqtVIedVSuEDUhHE5imKy2qrmlyWD3Rb8FiLT2BcWUKEchaNm4hjZwLTg=
X-Received: by 2002:a05:6402:2350:b0:5cf:3bd:46c6 with SMTP id 4fb4d7f45d1cf-5cf0a44166bmr1829597a12.27.1731063711430; Fri, 08 Nov 2024 03:01:51 -0800 (PST)
MIME-Version: 1.0
References: <172955108849.2082351.314284588549438876@dt-datatracker-78dc5ccf94-w8wgc> <SN7PR11MB6900E7F8CF85CE671D95A1FCC1432@SN7PR11MB6900.namprd11.prod.outlook.com> <CAOj+MMFVNZNK4k5H1RUHVpNr31gb8f3s5NYG69TR=Z1aCVAVew@mail.gmail.com> <CAOj+MMHDW1wPVNQqhBXCriEpTWOtiKEQMjYYZb2exEqny5MRCA@mail.gmail.com> <SN7PR11MB69004C7C1222D4669027970BC14C2@SN7PR11MB6900.namprd11.prod.outlook.com> <CAPF+HwVTjiMGct3sNkTtVhWs4OtgCJ5G06vAMvaLdw36hY4+4Q@mail.gmail.com> <CAOj+MMH3sicODQHs38vqvPtkEQYD42NpJOaLTzkJuX2DYMmy9w@mail.gmail.com> <CAPF+HwVRf=TMow=Yghr-YZQx_0L=E4m_620yy-3P51U+H98akw@mail.gmail.com> <CAPF+HwWC1ZGgvbKS8Z0T3Op0m+X+iUBL6wudzPWB7C=fRWzAAw@mail.gmail.com> <SN7PR11MB69002DF7293E3605F4153BB0C15C2@SN7PR11MB6900.namprd11.prod.outlook.com> <CAOj+MMHNdJ44gF=Lq2tWvpk3RwNt4cmo5VkR1uPT2X-LtmhPng@mail.gmail.com> <SN7PR11MB690000814FAE4A143E42AD4DC15C2@SN7PR11MB6900.namprd11.prod.outlook.com> <CAOj+MMGRxd4H6Ds4AbTJz2+GzZ-M0Mm8tAie=cWZgwwSPL-g6A@mail.gmail.com> <AC81F64B-2F19-4E91-A44D-5F7C04F468DD@pfrc.org> <CAOj+MMGDC4qriOTi5ozNUEi0HBQcX6zuc9tBkijFJLabZAYp1A@mail.gmail.com> <BBB6E88B-69DB-4D9E-9B88-B8DCCE7A182F@pfrc.org> <CAOj+MMGQi5XsQ0AOFSdMiDXVQurA=KuW7WVCTu6OF+vj61tYNQ@mail.gmail.com> <DC7C42B0-5C7F-4E6D-8FDA-EA5B958CF67A@pfrc.org> <CAOj+MMEESRaiDKBKYWs3oMkDZ=2-5TMK8fzGU0aX27jNoQ4XAg@mail.gmail.com> <3E72D444-5D53-46FC-BBB4-35C244DB0883@pfrc.org>
In-Reply-To: <3E72D444-5D53-46FC-BBB4-35C244DB0883@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 08 Nov 2024 12:01:40 +0100
Message-ID: <CAOj+MMFEj+bY24GfpzJsHXFzHXOGTnTY+x024RGOdx=pAst1hg@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: multipart/alternative; boundary="0000000000009a9858062664ad91"
Message-ID-Hash: KXFKO4FMISM5IUURDTYLMXHBGEWN3RNW
X-Message-ID-Hash: KXFKO4FMISM5IUURDTYLMXHBGEWN3RNW
X-MailFrom: robert@raszuk.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "idr@ietf.org" <idr@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dMfRKIxOgB4GHiqi9rcINMhvja4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Jeff,

> Ah, yes. Avoids sending routes to peers in the distribution graph that
don't want them.

You are still confusing filtering from RR to PE (side product which even RT
ORF could solve) from PE to RR or between ASNs where RT information on
senders pertaining to receivers would not be there in the first place. The
goal of constructing the graph and primary trigger for RTC was to
automatically build disjoined RR cluster RT membership wise as well as
prevent unneeded VPN routes to be propagated between ASNs doing VPNv4
peerings.

This is precisely what RTC RFC solves.

> So, if you find that required behavior generally problematic, you have an
issue with that RFC with your name on it.

You are simply wrong here on the primary goal of RFC4684 - please kindly
refrain from continuing misstating it.

You can stay with thinking that sender side filtering is always much better
then inbound drops. Your choice.

And sure we have ORF, RTC let's now add capabilities at OPEN to carry NLRI
filtering. Great for BGP - no doubt :(.

Thx,
Robert


On Fri, Nov 8, 2024 at 11:51 AM Jeffrey Haas <jhaas@pfrc.org> wrote:

>
>
> > On Nov 8, 2024, at 5:45 AM, Robert Raszuk <robert@raszuk.net> wrote:
> >
> > Hi Jeff,
> >
> > > What I find particularly perverse is that if you subscribe so deeply
> to the "just drop it" philosophy
> > > that you wasted your time on RFC 4684.  Perhaps you consider that RFC
> a heresy you wish to recant?
> >
> > You have completely misunderstood the primary objective of RFC4684 work.
>
> Not really.  I spend rather a lot of time working on bits of it.
>
> The implementation of the graph exists to provide selective filtering of
> VPN routes.  Absent such filtering, the default distribution mode of those
> VPN routes is "send them everywhere".
>
> PEs used to just drop them.  It was costly.
>
> The mechanism ... how did you put it?
>
>  "punching yet one more hole in efficient update replication"
>
> Ah, yes. Avoids sending routes to peers in the distribution graph that
> don't want them.
>
> So, if you find that required behavior generally problematic, you have an
> issue with that RFC with your name on it.
>
> Q.E.D.
>
> -- Jeff
>
>