[Idr] Re: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt
Jeffrey Haas <jhaas@pfrc.org> Thu, 07 November 2024 17:15 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 AF442C169401 for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 09:15:26 -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 WIdIZXJQfWhp for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 09:15:25 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A2845C151070 for <idr@ietf.org>; Thu, 7 Nov 2024 09:15:25 -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 EBDDC1E039; Thu, 7 Nov 2024 12:15:24 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_67B9E343-69D6-4F30-A4CC-4D18976CE21E"
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+MMGRxd4H6Ds4AbTJz2+GzZ-M0Mm8tAie=cWZgwwSPL-g6A@mail.gmail.com>
Date: Thu, 07 Nov 2024 12:15:24 -0500
Message-Id: <AC81F64B-2F19-4E91-A44D-5F7C04F468DD@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>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3696.120.41.1.10)
Message-ID-Hash: TPL254ETHE634V2STGLNIHP33PTVSZWV
X-Message-ID-Hash: TPL254ETHE634V2STGLNIHP33PTVSZWV
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/1J98zvhpZWFLaSrCQIhaPJd0ikE>
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, Firstly, thanks for pointing out the squatting. While I think the NX-OS case might possibly be internal-only, it does beg the question what their code does for the outside world. Ditto for FRR. Action item for the chairs is to address the squatting. Further commentary below. > On Nov 7, 2024, at 10:07 AM, Robert Raszuk <robert@raszuk.net> wrote: > Consider simple BGP topology: > > PE1 ---- RR ----- PE2 > | > ------- PE 3 > > Question 1: > > All PEs enable EVPN type 2. How is this expressed on the RR such that RR can push BGP route type capability to the peers ? > > Hint: Last time I checked RR cfg does not have any per type configuration ... 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. 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. > > 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. > 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
- [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