[Idr] Re: FW: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt
Ketan Talaulikar <ketant.ietf@gmail.com> Thu, 07 November 2024 13:47 UTC
Return-Path: <ketant.ietf@gmail.com>
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 1446DC15154A for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 05:47:18 -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, FREEMAIL_FROM=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=gmail.com
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 KzAd08IgIhMa for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 05:47:17 -0800 (PST)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 4C2DBC14F6F0 for <idr@ietf.org>; Thu, 7 Nov 2024 05:47:17 -0800 (PST)
Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-20c7ee8fe6bso10310045ad.2 for <idr@ietf.org>; Thu, 07 Nov 2024 05:47:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730987237; x=1731592037; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+Doim6mBw4u/y7H2+ZRx0RRRwrbSm6k/M+tr6yGdovo=; b=AIs1+F5cQuO6lPsx7o2HnaCA4tNBajdNBdIYpQ+qe3fxlFnGE3h+oVDEufvYdDmuy8 6kNsORQ1CSs4gLKxhfgDuXIvOtpR2xXsHALGUJFzqdIjT80ZHVGLfJodrjQNFNYtvtAb tzFftvKCrlOg0hEjkl5kNphqg76S+/fncT8byRj7oIbl5NubGpWEhhPnlCvGW45/D5c1 DZ9fQg9mQZtA3/HGcVJgBk04GKjug5CcZ1wxSthHP6xS1UQBBOk4N3CxsCVLTuiZG1+k MJLwPE2S0vavWd7ZGGtvLpFiIJqmdvtOvkox/ihU+dot20NEIr13Mn+AlRvIgfqmml0l r9pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730987237; x=1731592037; h=content-transfer-encoding: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=+Doim6mBw4u/y7H2+ZRx0RRRwrbSm6k/M+tr6yGdovo=; b=opT2sUukcjeonG7v8ihJzIJDbGVRNlSc3iqwriLQI39sUIFSpfczZCZib81dOYhIkE +LS+KzGH1NrXpwOcdKkGo0eJzNrLmOemsQmrm/HuCP86fi72GchNXLhBqPXpzZHRCoVM ouV5NM1vQpYyiY3yERzaHcaBHL9PcIABx7ePm8G6hkQ3YSxJdzSdxENgXHXIij7GTY6l QK6oXIBLPcumz5yuCvT19YRZhM0uUTa4Yuc6nBFp+gqxX7iuyiqwhjxzDz4jssbCQnYT n3GXtRlHSb60QLTk1tAVQ3Vno4OMxeSHzIpxalC7vbSH8KV1fiejaJa5RaS8jHdT+iuF +oIw==
X-Forwarded-Encrypted: i=1; AJvYcCXbqKFZzalR8tZf8o6sEAjvnAR6gdMK/iPBHKDDZ9dQN6fGXLTC7hj56j7fi5x2VjH9XGs=@ietf.org
X-Gm-Message-State: AOJu0Ywl8nnZyV30xyvATBRamuo3hhITKjuO6N3zjETEKrBfCeLK4qx7 vMbpgeLVUPr6IcmQX4r4DwEX3up2fF3lG4FXGyHIP3d3ksS6MnhJXZwiDOwM90/CS7gzWhlypOO 1vCFHnEC1q+OTKny2EbN3nTNzUbI=
X-Google-Smtp-Source: AGHT+IGoCqasFiWO/w2E6vl79cqc9T7YEtfgQvNkdjw6BWQa/LCI3SIPPC5M31xAccRLZ7NMep7YT7hS6sIKLQQkotQ=
X-Received: by 2002:a17:903:2287:b0:20d:284c:8d54 with SMTP id d9443c01a7336-210c6c1f299mr612417415ad.34.1730987236591; Thu, 07 Nov 2024 05:47:16 -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> <CAPF+HwUSjPGGokNVmC-_3JoxOamRSvEfp47kwoiseP=p1ED6GQ@mail.gmail.com>
In-Reply-To: <CAPF+HwUSjPGGokNVmC-_3JoxOamRSvEfp47kwoiseP=p1ED6GQ@mail.gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Thu, 07 Nov 2024 13:47:05 +0000
Message-ID: <CAH6gdPx9Yoqc7DwE0Q286Hn4K3oNdKB=2WLZzXgb+SEwrE3xXQ@mail.gmail.com>
To: Donatas Abraitis <donatas.abraitis@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: UGHPQ4N2FTIAQGWIFRVDJCODK2FR3U4X
X-Message-ID-Hash: UGHPQ4N2FTIAQGWIFRVDJCODK2FR3U4X
X-MailFrom: ketant.ietf@gmail.com
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: Robert Raszuk <robert@raszuk.net>, "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/JqqKEtD5EZbvACplYOkQuwLreq4>
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>
May I suggest that the implementers update this report: https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-dynamic-cap Thanks, Ketan On Thu, Nov 7, 2024 at 1:17 PM Donatas Abraitis <donatas.abraitis@gmail.com> wrote: > > FRRouting also has dynamic capabilities, but Robert is about dynamic capability not being defined as RFC yet (sad). > > On Thu, Nov 7, 2024 at 3: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 > > > > -- > Donatas > _______________________________________________ > Idr mailing list -- idr@ietf.org > To unsubscribe send an email to idr-leave@ietf.org
- [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