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

Robert Raszuk <robert@raszuk.net> Fri, 08 November 2024 10:45 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 97386C1D4A8F for <idr@ietfa.amsl.com>; Fri, 8 Nov 2024 02:45:32 -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 77Yx6xAqesEH for <idr@ietfa.amsl.com>; Fri, 8 Nov 2024 02:45:28 -0800 (PST)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 67E1FC151991 for <idr@ietf.org>; Fri, 8 Nov 2024 02:45:28 -0800 (PST)
Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a9ee097a478so106462466b.2 for <idr@ietf.org>; Fri, 08 Nov 2024 02:45:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1731062727; x=1731667527; 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=geqsCbUS1Yd3+2oWEaOGHB+qeCLF2NeeJwvv2n1+f0Q=; b=J1f5HNI7q4dBI0Sh5i4mVRFLr/++Kg/LC6OOlrusEhzc9MNLinXXEwP89zZ4NCErHf s88YjOy5/vp/vPGayBlMTVBie3qvtIllJEDt30/H6sLpjjo7+Xbzpb4+PWR3vB3Bdb7g K8InDduwoOVMni1bG9IN5JjjFb21qTqZyAdTdR1emGskLvn8gwmW2Q4XqTgrgu/eiaAr E3S2PVQYf7HackIcQsQ0uyMBEPtlKoqyAhmOgia98eqg1w4ISx2Nyb/uWjL8lDh/stJ+ cjygMCcAivaDvMwl5yOPnguRb/et92enuv9lFzZPFzhhbCZ44Toe64c+tv+tOi7cxCto pS9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731062727; x=1731667527; 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=geqsCbUS1Yd3+2oWEaOGHB+qeCLF2NeeJwvv2n1+f0Q=; b=Y6fFJmuhb+3leqEv2DlHD3MLIED+CA7K29mjZo3oBSzTsSDGRQSNGQKfEEhUzusnih HNx8oMJ+YCehl+wmW0q7PbzituBqmVyJLA99C7FghUSwfBJ6CMxtVRkIHVezUnW+q5c/ 0wPlpb8wvOKwdfGaTyc04avIigvQrfdoMr/r4aQ2nfNYYWPeOi9CQ8fXiuosFuC+4EOQ JBLq5vhXx2IwUP6cLRWoM6mAKGR37D4oA3WecCrLZcaBuS9hkCC5r9FhLEKEBorqJ5lX VqonyJFJlSfKXT4gypQ0+poF7NvtZ7XdbxdLCSusQ28GIESph0N/xRTBOQPKfC17SfUf m25w==
X-Forwarded-Encrypted: i=1; AJvYcCWkw3MhIc4l4l1neYGQ30KPB+Bzo5mBoCfnmpltevcvJ4ZDd2kcErZlWJJHeEOHtFuwYvY=@ietf.org
X-Gm-Message-State: AOJu0YwFofeNFb0I1z8Z0Vuvf0tiwXK+mYaYGmmRhRHSUbEJS+KQ1aYD zXojHNP3r4+ywsA5MQsnBO22weR7R+3p5pnb4B0LjQFfShcsGAR+yuAefBtRvLDKZFoWAijqYUb j/qCTyLWHtx/LNIpBeNOC5wPJHv3Y+oKv9bM1LpywVyOnP6Bksd8=
X-Google-Smtp-Source: AGHT+IFcZJyCiCFv8MKRUDckgtjrzycpcasnXipPR2CCfvDMvxVYr8lSiZlYIcJevUqDqKTiwR9gN2tHmMds12ujINY=
X-Received: by 2002:a05:6402:35d4:b0:5ce:af08:a2cd with SMTP id 4fb4d7f45d1cf-5cf0a446916mr2441438a12.33.1731062726529; Fri, 08 Nov 2024 02:45:26 -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>
In-Reply-To: <DC7C42B0-5C7F-4E6D-8FDA-EA5B958CF67A@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 08 Nov 2024 11:45:15 +0100
Message-ID: <CAOj+MMEESRaiDKBKYWs3oMkDZ=2-5TMK8fzGU0aX27jNoQ4XAg@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: multipart/alternative; boundary="000000000000e630620626647280"
Message-ID-Hash: VLLMPY5YAHUAZBNGZWPSJFGUSVK46WHC
X-Message-ID-Hash: VLLMPY5YAHUAZBNGZWPSJFGUSVK46WHC
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/QeNTzyhfIJuOAi8L-uZP4MjHq38>
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>

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.

The reason for defining new address family there was to build a intra-as
and inter-as graph of RT memberships.

In other words to propagate RT membership between BGP speakers.

RR to PE filtering was never the primary objective of RFC4684 - it is just
a side product of it.

Please (re)read the RFC paying special attention to the below sections
which I hope will make it clear to you:


Abstract

   This document defines Multi-Protocol BGP (MP-BGP) procedures that
   allow BGP speakers to exchange Route Target reachability information.




*   This information can be used to build a route distribution graph in
 order to limit the propagation of Virtual Private Network (VPN)   Network
Layer Reachability Information (NLRI) between different   autonomous
systems or distinct clusters of the same autonomous   system.*

...

Introduction




*   In such a scenario, as well as when VPNs may have members in more
 than one autonomous system, the number of routes carried by the
 inter-cluster or inter-as distribution routers is an important
 consideration.*

   In order to limit the VPN routing information that
*is maintained at a   given route reflector*, RFC 4364 [3] suggests, in
Section 4.3.3, the
   use of "Cooperative Route Filtering" [7] between route reflectors.
   This document extends the RFC 4364 [3] Outbound Route Filtering (ORF)
   work to include support for multiple autonomous systems and
   asymmetric VPN topologies such as hub-and-spoke.

   Although it would be possible to extend the encoding currently
   defined for the extended-community ORF in order to achieve this
   purpose, BGP itself already has all the necessary machinery for
   dissemination of arbitrary information in a loop-free fashion,

*both   within a single autonomous system, as well as across multiple
 autonomous systems.*

I hope at least this clarifies the misunderstanding of the real purpose of
RTC spec.

Thx,
R.


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

> Robert,
>
>
> > On Nov 7, 2024, at 3:21 PM, Robert Raszuk <robert@raszuk.net> wrote:
> > > > "punching yet one more hole in efficient update replication"
> > >
> > > Fine. Stop saying that. You're wrong.
> >
> > I (and not only I) beg to differ.
> >
> > It is well known that inbound filtering/dropping of updates are trivial
> and cheap operations as compared with continued mangling of sender's peer
> sets.
> >
> > If you disagree with that basic fact it is your problem, but please do
> not attempt to turn off the mic.
> >
> > Quote from Jakob in one of similar threads about pushing filtering up:
> >
> > "Receiving and matching on an RD to drop a route is just so trivial in
> comparison."
>
> Thank you for identifying Jakob's implementation as your example.  I'll
> note for the record that Jakob himself hasn't made these claims.
>
> Updates that are enqueued with the knowledge that they MUST be dropped at
> the receiver congests the route queues on an outbound basis, and wastes
> convergence time for updates containing routes that will have use at the
> receiver by making them do the work spinning their wheels to drop them.
>
> BGP permits this behavior.  I don't recommend it as an implementation,
> although quoting one of my elders, "My competitors are welcome to implement
> it this way."
>
> 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?
>
> -- Jeff
>
>