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

Robert Raszuk <robert@raszuk.net> Thu, 07 November 2024 17:33 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 9CCCFC17C882 for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 09:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_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 GBOghw9l6OEu for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 09:33:11 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 7D151C169431 for <idr@ietf.org>; Thu, 7 Nov 2024 09:33:11 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5cb615671acso785792a12.1 for <idr@ietf.org>; Thu, 07 Nov 2024 09:33:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1731000790; x=1731605590; 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=w3TYfSxNcUxWqwq1sdgxEU+5j2VVLjoxaBQeXC1ngqQ=; b=R+qIpA9e1hPPiRPuoGjwruJuO8zq1ON16SwNSAGjU2M5LugUrDIlfuBLlscHR9Wjdx RN0FMV03kKGs9+S4xQJI/zYBIs3XYLKxR1YhlakY5hEe0Qw9I8jYB+L4Oq813sX/oSTM EbM0ro7cOYkAeZU91FHbbEylQ2Zdald5UT+p9hgJ9c5PoFt0t/i5k5BusO4MH+bPc98E QM1+Y8NRvIkwmIRfKC/twiTkj1BsI+oxpc7wTd6yJFDugmeKFyTomLuIGP8IeKbb+mOY hhXLuOd5PALDnnB4wNRS+q4utFokkzQ/yY/FSHz//8TkCTWr76urLMh4pFx7XA8lxw8e R9Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731000790; x=1731605590; 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=w3TYfSxNcUxWqwq1sdgxEU+5j2VVLjoxaBQeXC1ngqQ=; b=cgtBiblzrbE7F72SWAQ9gnqCTFtzuackN3sw3OWfoTm+EmSfgRVUXltjP3wcCVc9w0 aKDgM8BseytIs7ZK/UChbv+CppVLifkJJEnImcpDLgTUs7kEqA07MefaBBWhrAPjrTSF qIQpYF9RR4iKPvAm6CJ8/pN5e2s7t9NzBC3CPYuBLHp69s0F5DSI59QqKFEnhSVeBkxg pKFqKIpF+kM0mvFo3G3pRz9BfiX1IDRgo9v5ctEhCkVqfoqPSrs0pw56fvBPSGrBBzCl E95AlO83iKTSoCSqztv2aeDcfRj/jDUWM9XyOlN2AEEfwJVP+JaQ3YDplfkdfiwYUGk4 BQCQ==
X-Forwarded-Encrypted: i=1; AJvYcCWsPFgjWCqdO12hk2y32/EgtW2QQd+XXekfCYi1cAfqbQXyNV59va2Kj/GgovIUWVIPj6w=@ietf.org
X-Gm-Message-State: AOJu0YxIUCOKyLDj/gvQL2fmSihHnX3Ftun5Y2LIAqdcX1zgoRFpgX6y hP343LMdFvGo9wN1a/ZEnRg4065sBo34DeciNKKEtBxzR9uSOPF7AfJK4YlfgFEykPbxeSmZa+H rXWG0tbPQ3m2Rsc9tU3PrKespN+q4zmkDtqBcxQ==
X-Google-Smtp-Source: AGHT+IGCv9gvTyT/qRaNaZyQPmqb2wUVrlWwbOvDjsaaizi0g0zWxWxVwWtQk0N2luxgun/sYnC3GJI4tZ5kERpQrbE=
X-Received: by 2002:a05:6402:234b:b0:5cf:50f:f2e1 with SMTP id 4fb4d7f45d1cf-5cf098bcb62mr304905a12.22.1731000789678; Thu, 07 Nov 2024 09:33:09 -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>
In-Reply-To: <AC81F64B-2F19-4E91-A44D-5F7C04F468DD@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 07 Nov 2024 18:32:58 +0100
Message-ID: <CAOj+MMGDC4qriOTi5ozNUEi0HBQcX6zuc9tBkijFJLabZAYp1A@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: multipart/alternative; boundary="0000000000002cdd96062656079e"
Message-ID-Hash: XYODWBKSA4O35SCJSDL46FNA5GFRWPQX
X-Message-ID-Hash: XYODWBKSA4O35SCJSDL46FNA5GFRWPQX
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/df3zixxfygQ9oK9N_TKYv4jxzWU>
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,

There's two forms of filtering that the draft would be able to implement:
> 1. This devices locally supports this types.  This is the minimally useful
> thing to prevent reset problems from inconsistent incremental deployment.
> The only thing that should cause this to change is a software upgrade.
> Absent non-stop-routing considerations, that probably involves a session
> bounce.
>

NLRIs do not come out of the blue.

The fact that a new OS version which supports a new type-X is added to
the network will not cause any of the session reset.

Only when configuration is applied to generate such NLRI with type-X non
upgraded boxes MAY reset the session.

One point hers is that configurations should be tested before they are
applied to production networks.

Second point here is that if you need to upgrade old equipment to support
new capability advertisements upgrade them with knob not to reset the
session.



> 2. This device supports type X, but wants to filter it by configuration.
> Conveniently this one is indistinguishable from 1, but does beg the cases
> noted in the thread about whether dynamic renegotiation is needed.
>
> The second case also begs the question of whether there's use cases for
> uni-directional filtering.  I suspect that bi-directional support covers
> the majority of use cases that BESS has worked on, but I don't deeply
> follow their full work.
>

I do not see a relation here to bi/uni-directionality of this. The point
here is about IBGP sessions (say EVPN) are advertising today from PEs or
RRs without per peer type config. So all what VRFs facing edges produce
get's sent.


> Well .. by pushing the capability at the beginning of the BGP session or
> dynamically later you are not avoiding "inadvertent dropping of updates".
> What you are doing is just pushing the drops from client to sender (among
> other drawbacks punching yet one more hole in efficient update
> replication).
>
> I rather wish you'd discontinue stating this.  It's been contradicted
> on-list multiple times.
>
> For circumstances where you're filtering stuff, there's no need to "break
> the update groups".  You're selectively sending the updates to a subset of
> the peer in the peer-group.  RT-Constrain does exactly this behavior for
> VPN routes based on membership.
>
> If you believe this is actually a problem, please feel free to identify
> the implementations that have it for public ... commentary.
>

Where did I say anything about *"breaking update groups"* above ???

All I am stating is that filtering on egress requires special handling
(dividing peers into subsets or filtering on the fly post replication -
depending on the implementation) when compared with inbound filtering drop.

That was my point.

Rgs,
R.

> I suggested using an ORF message instead. Did not receive any technical
> arguments why such a solution to accomplish update drops on the sender side
> would not be a much better option. At least the path to standardizing the
> new ORF type would be much much easier than the current dead end street you
> are entering ...
>
> An ORF might not be a terrible mechanism if this was expected to be
> dynamic.  The main use case (1) is full lack of support rather than
> filtering.
>
> Another argument for doing this at OPEN is that lack of propagation of
> certain types might be reason to not permit the session to establish.  To
> head off the usual capabilities "negotiation" argument, capabilities
> advertisement shouldn't do this by default.  However, it's permitted
> operationally.  See RFC 5492, §3 ¶5.  Arguably, that bit of RFC means we
> should also think carefully what the NOTIFICATION DATA field should contain
> if this happens.
>
> -- Jeff
>
>