[Idr] Re: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt
Robert Raszuk <robert@raszuk.net> Thu, 07 November 2024 20:21 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 43572C1ECA95 for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 12:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_NONE=-0.0001, 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 W0nllzvaSm7B for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 12:21:36 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 8AA7AC217BC3 for <idr@ietf.org>; Thu, 7 Nov 2024 12:21:30 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-539f4d8ef84so1692941e87.0 for <idr@ietf.org>; Thu, 07 Nov 2024 12:21:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1731010889; x=1731615689; 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=nXvSK9OUlxus4Dit5xgKTuSvBQVuRufHvisVymoA33c=; b=QsGIzZSVwB5R83jlI/rmUbUPBXwk07Kagr7ZjPmYQAaWc14SkDyntHE23YClzJqGuj WHhzFeKMJOcM4S46Os3QVCwF0Le982jqhy9SQTmoDU7ZDKtBfb7zID4J8LT8Bc1/9KqV aqKGosW41vIu+Bg4dnisBYjU5r+pfhvigZNrrZ0AOmF+oeLqucWfJ4PSyjAe8kAJ3q/J JQNMQIqM7e6Zdoyu9HZpd09YpU2MvrQCcNoyshpfmMt6Mj88amYeGiHq8vEmLma9mzgm Ua+MlbC7kB5BzeKYgI2fplqISfMGFAuwsmwlUrnxZSMQrPBw6XfAS4Yx782U+BgWeXIm WqMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731010889; x=1731615689; 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=nXvSK9OUlxus4Dit5xgKTuSvBQVuRufHvisVymoA33c=; b=E61uf5RfGFk1j2JKq1z4oUCudi/l36EjRJ+g4iag+ViTDkap+o6Zfpzrq6JkmMhY5U 40dnPPZ1pGqWOXUrmP0i4Z9xBt7qx+ZR+rtcB9jqUFwPa3jeeIVtHm6IBbKviqcOnUyb gUOoXW+r0zPguTTVrXb8BbB7P53Yn7i8V4jFN/eo2hZcyROIKJ9E3itd7Z6Ltkqhvg8H QqGB8OY5s4LLIAP3grsEjpj7/REr6muUTl47e642Vwfl4kb+d+eE0pdpgdrwTo/2tkyF klehSutTLOkpchRD66ze+KRy3JmdneL/9oj1V86OKVrtZVFcLURdMh4G1uqvaomqwWoU /gSw==
X-Forwarded-Encrypted: i=1; AJvYcCXHF9PL97TcbhU1UI0iRpyTYN+ETPKRwq512saG8CxmJlY0c0EUTKFAX5KVM0eL/9SDAto=@ietf.org
X-Gm-Message-State: AOJu0YzHAk/RWzQeZPjqJiK21NOx3WuddjVefN1xbGaFelsqkdLigCHY YzdxbC7rDyC6cFw7pm/HWVOz/+101whegyEvbUmsTvR6ehU7aw66QlcjPi2cLakd0T62V+HVx/L CzkExylh/femk07ErCuIpoVnhvVVSW8WAoCw4UPhKvvnIrYMBd8M=
X-Google-Smtp-Source: AGHT+IG2iG80kkae2Lts7yzi7hAl7jLuttfZJvnI770KAufF80Q9hh2rxcDI/9JKFq7o9ZWHyCfrHLGWaYswvyWHeEg=
X-Received: by 2002:a05:6512:3d1d:b0:539:fc45:a292 with SMTP id 2adb3069b0e04-53d8626c94amr261841e87.43.1731010888355; Thu, 07 Nov 2024 12:21:28 -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>
In-Reply-To: <BBB6E88B-69DB-4D9E-9B88-B8DCCE7A182F@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 07 Nov 2024 21:21:17 +0100
Message-ID: <CAOj+MMGQi5XsQ0AOFSdMiDXVQurA=KuW7WVCTu6OF+vj61tYNQ@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: multipart/alternative; boundary="0000000000001a70f80626586100"
Message-ID-Hash: N2CVBPNHDIMFSUY64HCRJWD23CO2CTFW
X-Message-ID-Hash: N2CVBPNHDIMFSUY64HCRJWD23CO2CTFW
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/-JdMdpXLyp1l4EHmMqd7ekxvh0s>
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, Two comments ... *#1 * The problem is most likely (as you acked) to be seen on PEs. So by my books we should do all what it takes to pinpoint the node where the root of the problem is ... not mask it with a bandage only to extend a remote shield .. sometimes 100s of miles away from the problematic node. This draft does exactly that ... masking the real issue. *#2 * > > "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." Note here is even easier than per RD check :) REF: https://mailarchive.ietf.org/arch/msg/idr/wcBqVsQ_MdNGtrZDPP1VcVYJu7Q/ There are similar quotes from other folks, but I do not have time to search to prove the obvious. If I get really bored one day maybe comparing times of various implementations and publishing them for sender vs receiver based filtering may be something that will convince you ... Best, Robert On Thu, Nov 7, 2024 at 7:34 PM Jeffrey Haas <jhaas@pfrc.org> wrote: > Robert, > > > On Nov 7, 2024, at 12:32 PM, Robert Raszuk <robert@raszuk.net> wrote: > > 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. > > > From the perspective of a given device, they might. :-) > > > 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. > > > We're having this conversation partially because that's not always true. > > Arguably from an RFC 7606 perspective, everyone should be following §5.4. > > > 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. > > > You're presuming that new feature always means new configuration. That's > not a given. > > > 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. > > > That's the RFC 7606 point. I agree with you on that. :-) > > >> 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. > > > It's also the RR to the PE. PEs with lagging support are far more often > the problem. > > I'm not convinced that there's asymmetry here, but I wanted to raise the > point for discussion. > > While much of the core of the original proposal is targeted toward > potential issues in implementations that can't / doesn't want to handle > some NLRI's route type, a case I find generally compelling is simply > hardening a deployment's edge vs. new features. Many of our issues related > to attribute-escape is some feature doesn't have a crisp edge where > filtering can be done. Support for a given route-type is one such boundary. > > Absent signaling on the route-type, other capabilities may be > appropriate. That's understood. This is just one more tool for the > toolbox. > > > >> 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 ??? > > > "punching yet one more hole in efficient update replication" > > Fine. Stop saying that. You're wrong. > > > 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. > > > And clearly most larger implementations have figured out how to do it > without copy and paste or hard loops over the peer list that is in sync. > > If your exemplary implementation hasn't, there's likely someone you could > hire to address that. Again, feel free to name said exemplary > implementation for ... commentary. > > -- Jeff > >
- [Idr] FW: New Version Notification for draft-kris… Krishnaswamy Ananthamurthy (kriswamy)
- [Idr] Re: FW: New Version Notification for draft-… Robert Raszuk
- [Idr] Re: FW: New Version Notification for draft-… Robert Raszuk
- [Idr] Re: FW: New Version Notification for draft-… Krishnaswamy Ananthamurthy (kriswamy)
- [Idr] Re: FW: New Version Notification for draft-… Donatas Abraitis
- [Idr] Re: FW: New Version Notification for draft-… Robert Raszuk
- [Idr] Re: FW: New Version Notification for draft-… Donatas Abraitis
- [Idr] Re: FW: New Version Notification for draft-… Donatas Abraitis
- [Idr] draft-kriswamy-idr-route-type-capability-00 Jorge Rabadan (Nokia)
- [Idr] Re: draft-kriswamy-idr-route-type-capabilit… Krishnaswamy Ananthamurthy (kriswamy)
- [Idr] Re: draft-kriswamy-idr-route-type-capabilit… Jorge Rabadan (Nokia)
- [Idr] Re: FW: New Version Notification for draft-… Krishnaswamy Ananthamurthy (kriswamy)
- [Idr] Re: FW: New Version Notification for draft-… Robert Raszuk
- [Idr] Re: FW: New Version Notification for draft-… Krishnaswamy Ananthamurthy (kriswamy)
- [Idr] Re: FW: New Version Notification for draft-… Donatas Abraitis
- [Idr] Re: FW: New Version Notification for draft-… Ketan Talaulikar
- [Idr] Re: FW: New Version Notification for draft-… Robert Raszuk
- [Idr] Re: New Version Notification for draft-kris… Jeffrey Haas
- [Idr] Re: New Version Notification for draft-kris… Robert Raszuk
- [Idr] Re: New Version Notification for draft-kris… Jeffrey Haas
- [Idr] Re: New Version Notification for draft-kris… Robert Raszuk
- [Idr] Re: New Version Notification for draft-kris… Jeffrey Haas
- [Idr] Re: New Version Notification for draft-kris… Robert Raszuk
- [Idr] Re: New Version Notification for draft-kris… Jeffrey Haas
- [Idr] Re: New Version Notification for draft-kris… Robert Raszuk
- [Idr] Re: New Version Notification for draft-kris… Jeffrey Haas
- [Idr] Re: New Version Notification for draft-kris… Robert Raszuk