[Idr] Re: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt
Jeffrey Haas <jhaas@pfrc.org> Thu, 07 November 2024 18:34 UTC
Return-Path: <jhaas@pfrc.org>
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 7A520C20C8FA for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 10:34:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 fSTBsu6j4vI1 for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 10:34:38 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA23C1ECA82 for <idr@ietf.org>; Thu, 7 Nov 2024 10:34:38 -0800 (PST)
Received: from smtpclient.apple (172-125-100-52.lightspeed.livnmi.sbcglobal.net [172.125.100.52]) by slice.pfrc.org (Postfix) with ESMTPSA id 4BB4B1E039; Thu, 7 Nov 2024 13:34:37 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CB2E023A-B4C5-4A62-B1B3-2626BE853117"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CAOj+MMGDC4qriOTi5ozNUEi0HBQcX6zuc9tBkijFJLabZAYp1A@mail.gmail.com>
Date: Thu, 07 Nov 2024 13:34:36 -0500
Message-Id: <BBB6E88B-69DB-4D9E-9B88-B8DCCE7A182F@pfrc.org>
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>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3696.120.41.1.10)
Message-ID-Hash: 4LQPLRLSP6NFUVWARCBIRN6ONZ4T4VZX
X-Message-ID-Hash: 4LQPLRLSP6NFUVWARCBIRN6ONZ4T4VZX
X-MailFrom: jhaas@pfrc.org
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/IZmfcMCjPGmZ3krbn9alygxUhhM>
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>
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