[Idr] Re: FW: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt
Robert Raszuk <robert@raszuk.net> Thu, 07 November 2024 15:08 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 15C24C14F5E8 for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 07:08:11 -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 ICeDVCzUJ_OJ for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 07:08:06 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 BAEE9C169408 for <idr@ietf.org>; Thu, 7 Nov 2024 07:08:06 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5cacb76e924so1614659a12.0 for <idr@ietf.org>; Thu, 07 Nov 2024 07:08:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1730992084; x=1731596884; 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=HD9QC+F7rm2MF7jaqvajog1hz5UGCE6pSHAx5bBTJEY=; b=QkvDmR5CDgKRZh1RY/2sgWZ+CLnvWNVOZ6bMyrAfXDWrRwfKGzmZ2uoXOuQ9faIXVd brQLGmhop2G8u561lUcSrykZ4LZ9BoV4W0u5JylfLn+CT1n9Ii7lSC5Nbbfyh/5fm6Gr zLH49u0PF3XVOPQb5Stgram5hKvPoMSXLjYf8CDoU1m/mQjhoylyl+3lxJcuMOTNAbYP 5QoYAPUpqEz+6VcxWOz3S5WwWhCaAtSp3KkMkSmMABz30M1G0K1jU3pNYAfqI8UNDW/L yxvg5zTgi7jo8W4tMVcj9Y3ztI1/vnbhBYS7Z8QeVxoi08fJ+oeVOPUlGYK57s0CfG9x qFgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730992084; x=1731596884; 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=HD9QC+F7rm2MF7jaqvajog1hz5UGCE6pSHAx5bBTJEY=; b=H7LatKf7MZsNgirJobNDzbSOXg5jTG0Vgw8vBAOH4Npj6GVRPigjTsKwXXFO6oBYtj 9bYb/7W9db9lXlS+xO/chWlQt+zo4qVg5NW02IML0vNbbmB7t8Ri7MbUrlyrgVTx4EWp yVBNJNSKmafKSlV9EL3cAxiGrNHdg0u07HHZ4Nq56PqUTT1W2msACEgCDZdrhE6VwOvL dIyjYrUyEv4Oj9uFOHsMnlWv+kjki9DCNzMEHPbA/yidqfPaHbmAFpA8J0p2Hf+3jzaC yQGDvQoSa3IUBFhPj9VvU8/ZpxMi59MmZYYQmFfotT6k/kj2Qtmjs3o5H+s48Dfplgob XixQ==
X-Forwarded-Encrypted: i=1; AJvYcCXq+dDgdqgPuXhJL7cBZ7QkskzGh33StWTw4WGZAJ4KY4g1bGcnYZIW0SQFZTPg5ldo6eA=@ietf.org
X-Gm-Message-State: AOJu0Yy+jiLQkKFpKIlSok90UQJReDpe8DgN8Nr1vKPEbTETW0uj38++ C9CWp/yFwz9lhBtcIQeWVXDU6xyTqXO6ehv7ip4POGsFAEObEaoXw9wgj4i8ywhJTk6PQD/wYk5 mAwv9KfBcVgRG5wK7WN0N7q07X5dfnBodGsu2+w==
X-Google-Smtp-Source: AGHT+IGR6GFpp0QThOx6PEokG0CAxgKe3H0OdWkL6T/yaF2pitU262zCtMLNlx8jhhy8mpEE42BmTdXTXTqQyiCvaJg=
X-Received: by 2002:a05:6402:2114:b0:5ce:d028:e11 with SMTP id 4fb4d7f45d1cf-5ced0280e56mr13819647a12.17.1730992084012; Thu, 07 Nov 2024 07:08:04 -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>
In-Reply-To: <SN7PR11MB690000814FAE4A143E42AD4DC15C2@SN7PR11MB6900.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 07 Nov 2024 16:07:52 +0100
Message-ID: <CAOj+MMGRxd4H6Ds4AbTJz2+GzZ-M0Mm8tAie=cWZgwwSPL-g6A@mail.gmail.com>
To: "Krishnaswamy Ananthamurthy (kriswamy)" <kriswamy@cisco.com>
Content-Type: multipart/alternative; boundary="00000000000046ef420626540088"
Message-ID-Hash: PFLGAPHOF7PAUYTDMXAL3BUZUBLPKGR5
X-Message-ID-Hash: PFLGAPHOF7PAUYTDMXAL3BUZUBLPKGR5
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: FW: 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/332wK0pMTfdgokJM-owz_bbty-Y>
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 Krishnaswamy, Good to know that NX-OS implemented dynamic capabilites. Was this ever well tested ? Clearly there is codepoint squatting for the new BGP Message type (so pretty severe operationally), but let's put that aside for now. As I recall when we had early implementation of dyn capabilities in IOS classic there was lot's of issues discovered during testing hence it was abandoned. I hope your implementation is much better and that you are planning to update BGP FSM too to reflect the changes. But let's come back to the core of the new draft. 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 ... address-family l2vpn evpn neighbor 172.16.255.3 activate neighbor 172.16.255.3 send-community both neighbor 172.16.255.3 route-reflector-client *Observation: * Your draft says: "This framework facilitates the maintenance of sessions without necessitating resets *or the inadvertent dropping of updates.*" 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). So technically a simple knob on the client which today *MAY* reset the session would be sufficient not to reset the session when receiving unrecognized NLRI types for the multi-type AFI/SAFIs. *Question 2: * 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 ... Regards, Robert On Thu, Nov 7, 2024 at 2:11 PM Krishnaswamy Ananthamurthy (kriswamy) < kriswamy@cisco.com> wrote: > Hi Robert, > > Cisco NX-OS has implementation of the Dynamic capability. > I have discussed with Enke during IETF 120 and also with Jeff Haas on NXOS > implementation. > > Thanks > > Krishna > > > > > > *From: *Robert Raszuk <robert@raszuk.net> > *Date: *Thursday, November 7, 2024 at 11:24 AM > *To: *Krishnaswamy Ananthamurthy (kriswamy) <kriswamy@cisco.com> > *Cc: *Donatas Abraitis <donatas.abraitis@gmail.com>, idr@ietf.org < > idr@ietf.org> > *Subject: *Re: [Idr] Re: FW: New Version Notification for > draft-kriswamy-idr-route-type-capability-00.txt > > Hi, > > > > Dynamic capability does not exist - it was never implemented per full spec > you are quoting as normative reference. > > > > There was an attempt by Enke to implement a subset of it just to avoid > session reset when adding/removing address families but this also did not > go far. > > > > So with that I do not think this addition to the spec is helpful. > Furthermore I don't think spec can progress with Normative Reference being > a non implemented draft. > > > > Cheers, > > Robert > > > > > > On Thu, Nov 7, 2024 at 12:19 PM Krishnaswamy Ananthamurthy (kriswamy) < > kriswamy@cisco.com> wrote: > > Hi Donatas, > > Operation section is added to the “01” version. Also added > text on how to dynamically send this capability. > > Thanks > > Krishna > > > > > > *From: *Donatas Abraitis <donatas.abraitis@gmail.com> > *Date: *Wednesday, October 23, 2024 at 12:33 PM > *To: *Robert Raszuk <robert@raszuk.net> > *Cc: *Krishnaswamy Ananthamurthy (kriswamy) <kriswamy@cisco.com>, > idr@ietf.org <idr@ietf.org> > *Subject: *Re: [Idr] Re: FW: New Version Notification for > draft-kriswamy-idr-route-type-capability-00.txt > > Also, we might need another Cease NOTIFICATION message that would tell us > to retain the routes > > (while _updating_ new route types) combined with Graceful-Restart > Notification support? > > > > On Wed, Oct 23, 2024 at 2:29 PM Donatas Abraitis < > donatas.abraitis@gmail.com> wrote: > > But then... Without dynamically sending (dynamic capability or another > type of message?) this capability it's _hard_ to imagine how it would work > correctly. > > > > Clearly, as Robert said, the operational section is a MUST here. > > > > On Wed, Oct 23, 2024 at 2:23 PM Robert Raszuk <robert@raszuk.net> wrote: > > It is not as sweet as it looks :) > > > > List of route types keeps getting extended in multi route-type AFI/SAFIs > .. so you really never know what is supported by the peer unless you know > how to operate your network well. > > > > I think the proposal is a safety fuse to address not so well operated > networks ... > > > > Cheers, > > R. > > > > On Wed, Oct 23, 2024 at 12:21 PM Donatas Abraitis < > donatas.abraitis@gmail.com> wrote: > > What optional route types would be advertised? I mean if an implementation > supports let's say EVPN, LS, etc. does it > > include all of them or the _list_ should be configurable? > > > > On Tue, Oct 22, 2024 at 10:12 PM Krishnaswamy Ananthamurthy (kriswamy) > <kriswamy=40cisco.com@dmarc.ietf.org> wrote: > > Hi Robert, > > Appreciate your quick review and feedback, and the following is the > response. > > > > #1 – Will update the text > > #2 – Will expand the operation section and will consider your suggestion > > #3 – Will discuss with co-authors and respond accordingly. > > > > Thanks > > Krishna > > > > > > *From: *Robert Raszuk <robert@raszuk.net> > *Date: *Tuesday, October 22, 2024 at 1:59 PM > *To: *Krishnaswamy Ananthamurthy (kriswamy) <kriswamy@cisco.com> > *Cc: *idr@ietf.org <idr@ietf.org> > *Subject: *Re: [Idr] FW: New Version Notification for > draft-kriswamy-idr-route-type-capability-00.txt > > All, > > > > Actually I have a 3rd comment which appeared after I hit the send button. > > > > Since you are really doing route type filtering here it seems to me that a > much better suited mechanism for this would be an ORF message. > > > > In fact it is also much more flexible - you can freely use it during BGP > sessions being already established without need for session reset to enable > reception of new service/new NLRI types. > > > > A simple extension would be like Dynamic Route-Types support with most of > the existing cfg/cli/show commands or logging already in place. > > > > Think about it .... > > > > Cheers, > > Robert > > > > > > On Tue, Oct 22, 2024 at 6:08 PM Robert Raszuk <robert@raszuk.net> wrote: > > Hi, > > > > I have two comments on this draft. > > > > #1 > > > > Draft says: > > > > > This document defines an optional capability exchange of route types > > > per AFI/SAFI such that BGP speakers *negotiate* the route types > > > > Unfortunately BGP capabilities do not negotiate anything in BGP. Please > search on number of discussions on this point on the list in the past. > > > > So I recommend you change this into: > > > > This document defines an optional capability exchange of route types per > AFI/SAFI such that BGP speakers *signal* the route types > > > > #2 > > > > Operational consideration is missing ... > > > > The scenario where this draft could play a role is that operator enables > mix of services between two nodes. > > > > Now this mix of services is not symmetrical. > > > > Today session does not come up and it is clear there is configuration > mistake which needs to be corrected. > > > > With this draft session will happily come up and only "supported" services > by a peer as expressed in supported route types for a given AFI/SAFI peer > will be sent. > > > > How is this helping operator to consistently run the services ? If he > would not count on exchanging those with the peer it would not be > configured in the first place. > > > > Bigger question how would a router signal that only partial of configured > services operate within say EVPN AF ? > > > > It seems that it would lead to really weak configuration habits in a style > - enable all and see what get's exchanged. > > > > In other words having ability to know what services/route types my peers > support for a given AFI/SAFI seems cool. But only informationally. > > > > Using this information for automated service propagation > suppression/filtering is IMHO much less cool .. if at all a good thing. > > > > Kind regards, > > Robert > > > > PS. And it may be interesting to see a section on how this may help to > enable new route types dynamically on the existing running nodes and within > existing established BGP sessions with many AFI/SAFIs. Of course assumption > is that running operating systems on those nodes does support it already - > but new services where not enable at boot time (BGP sessions establishment > time). > > > > Where am I going with this PS note ... > > > > As we are really touching a new territory of signalling embedded route > types (different NLRI formats) within single AFI/SAFI(s) perhaps this is > good time to rethink it and write up Dynamic Route-Types proposal which > could be signalled between nodes not really using BGP Capabilities > semantics. > > > > > > On Tue, Oct 22, 2024 at 12:58 AM Krishnaswamy Ananthamurthy (kriswamy) > <kriswamy=40cisco.com@dmarc.ietf.org> wrote: > > IDR WG, > > We have posted a new draft outlining route type capability to address BGP > session reset whenever new route type is added to address families like > EVPN. > > > > > https://datatracker.ietf.org/doc/html/draft-kriswamy-idr-route-type-capability > > Request the WG to review and provide feedback/comments. > > Thanks, > Krishna > > > > *From: *internet-drafts@ietf.org <internet-drafts@ietf.org> > *Date: *Monday, October 21, 2024 at 5:51 PM > *To: *Keyur Patel <keyur@arrcus.com>, Krishnaswamy Ananthamurthy > (kriswamy) <kriswamy@cisco.com>, Lukas Krattiger (lkrattig) < > lkrattig@cisco.com>, Mankamana Mishra (mankamis) <mankamis@cisco.com> > *Subject: *New Version Notification for > draft-kriswamy-idr-route-type-capability-00.txt > > A new version of Internet-Draft > draft-kriswamy-idr-route-type-capability-00.txt has been successfully > submitted by Krishnaswamy Ananthamurthy and posted to the > IETF repository. > > Name: draft-kriswamy-idr-route-type-capability > Revision: 00 > Title: BGP Route Type Capability > Date: 2024-10-21 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/archive/id/draft-kriswamy-idr-route-type-capability-00.txt > Status: > https://datatracker.ietf.org/doc/draft-kriswamy-idr-route-type-capability/ > HTMLized: > https://datatracker.ietf.org/doc/html/draft-kriswamy-idr-route-type-capability > > > Abstract: > > BGP supports different route types, which defines the encoding of > Network Layer Reachability Information (NLRI) for a some of the > Address Family Identifier (AFI)/Subsequent Address Family Identifier > (SAFI) like Ethernet VPN (EVPN), Multicast VPN(MVPN) and so on. BGP > speaker will reset the BGP session if a given route type is not > supported. This document defines an Optional Capabilities to > exchange the route types supported for a given AFI/SAFI such that > session are not reset. > > > > The IETF Secretariat > > _______________________________________________ > Idr mailing list -- idr@ietf.org > To unsubscribe send an email to idr-leave@ietf.org > > _______________________________________________ > Idr mailing list -- idr@ietf.org > To unsubscribe send an email to idr-leave@ietf.org > > > > -- > > Donatas > > > > -- > > Donatas > > > > -- > > Donatas > >
- [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