[Idr] Re: FW: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt

Robert Raszuk <robert@raszuk.net> Thu, 07 November 2024 11:24 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 1E060C151080 for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 03:24:04 -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 HmcuJZ11LHS5 for <idr@ietfa.amsl.com>; Thu, 7 Nov 2024 03:23:59 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 D2F6CC1E0D93 for <idr@ietf.org>; Thu, 7 Nov 2024 03:23:59 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5cec9609303so877978a12.1 for <idr@ietf.org>; Thu, 07 Nov 2024 03:23:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1730978638; x=1731583438; 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=pQ8NPt886GwnHEGHNKt/laTDQAoZ0HHO07i4vkVGquQ=; b=elKH0LDaNdRXpMIELW6j65Va4mrw5Ye5+T9vCS7GB5X7mqcWKTebCasZiBh5IaEH06 aDGit+CJlevuyPwokd5XzHE7xTtnpjH4eD0doeI8xZd/M/jzP3rqetsscsO+/B4z+38O LB9TMriODx+Po1CCIudtvFHs/YUx2mTr/2Qtrx2WZJ4lOP3qbvCsOaL6wfJTRehUAUF0 S7bNX/HLWdMQZpuipyPQx5WmqqJUBBVS2iIM4R54cm2zKsz8tpe9ujWiSY4dNM0RfUOz VyDrZhN7UQND24n0aIAey2qRFPsqP9+HA4/awA7byUySuX00FlYu/jjH9lhlYLxVXj1K e2Og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730978638; x=1731583438; 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=pQ8NPt886GwnHEGHNKt/laTDQAoZ0HHO07i4vkVGquQ=; b=GdGHIncFjMmLrQjr/Yy7QFZSRifI3QPuaP4eUkyQimglz/iTZRFY+KJFNDlrHyFKkW raYRL7FA5S3IS5p+yQkahOfj9XwB2dub3NOqA7npdb0b/Yc4shEWrekcUzLJuETVpyrx WIY8a7C+uIGYdcpCwdA981RWN5Opr+ugS8Y9GP+hl6dWu3jwCFWIlZGW/lZtPjpIo+GT euv6N1OuidRd/FCgL8wxTQXKjwdB3jbht2YbMYh/xVD8E3bNACmIemPZjTPgnG3G3u+q AJCTwTDyPUC1RsguMyblCeErdcOtGvMiUPZKVlUP+I6WaEmjjE2xg/q7PpBnmsN6FWYV O60g==
X-Forwarded-Encrypted: i=1; AJvYcCVVeDZhxkCs9/ggh7CZxH1zJAccPBiCXXiawpvcvzjjBH7Au799RbSlJSq4yKDgfFrSINA=@ietf.org
X-Gm-Message-State: AOJu0Yz4WZc7tZxGvh6fJNcQhzS1HgDeFPuxctmaCmKMD28i2LXt+s5l Gkuz8L1zPf2HU7yjujwdhCKIHZtOyFJ13Xo6LaBpjtCb7LgBQiNFmDpy4qBKJeuDZle+lvAFaHn 2EGwgRCcxXMQUQb+NjgkSF9RixMk+s/10KInUuEqNsiZ0gQFW
X-Google-Smtp-Source: AGHT+IGDlcKfoq8lPal7j6Lxeo5er6si9zYX8nPFKCvjZHdgW71H4WrXh/3RkmM/C84GNPL8W0aTc9y3Q+lRVXM7qzw=
X-Received: by 2002:a05:6402:13cb:b0:5ce:dc4e:57ff with SMTP id 4fb4d7f45d1cf-5cedc4e6163mr10959334a12.24.1730978637579; Thu, 07 Nov 2024 03:23:57 -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>
In-Reply-To: <SN7PR11MB69002DF7293E3605F4153BB0C15C2@SN7PR11MB6900.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 07 Nov 2024 12:23:46 +0100
Message-ID: <CAOj+MMHNdJ44gF=Lq2tWvpk3RwNt4cmo5VkR1uPT2X-LtmhPng@mail.gmail.com>
To: "Krishnaswamy Ananthamurthy (kriswamy)" <kriswamy@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000cea7d5062650de29"
Message-ID-Hash: ZUX42DVYYQYIIJJ2YHXKWDLXN7FSKLSS
X-Message-ID-Hash: ZUX42DVYYQYIIJJ2YHXKWDLXN7FSKLSS
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/hiumxeJ-25wdsjr76UJMqQE-ixs>
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,

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
>