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

Robert Raszuk <robert@raszuk.net> Tue, 22 October 2024 16:09 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 402A1C169432 for <idr@ietfa.amsl.com>; Tue, 22 Oct 2024 09:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_NONE=-0.0001, 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 7aAfpVFWhdCp for <idr@ietfa.amsl.com>; Tue, 22 Oct 2024 09:09:03 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 7CD7AC169427 for <idr@ietf.org>; Tue, 22 Oct 2024 09:09:03 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5c9693dc739so7614537a12.3 for <idr@ietf.org>; Tue, 22 Oct 2024 09:09:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1729613341; x=1730218141; 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=Rc9fm6Hfw8AXu+RwSaqa1sqHwQrNjY3G32u+RXEGjR0=; b=KmieZYLidz347EFaeySBtHDvR3oHBrsKPsWS8l2IYkvJ69Xtf1cSG5lbUG/0P+f7nI FnO/hqfO5bNNrBMvvl5yiEMnwycYkjy21VTyNRo4Pjq7lBS8xjVmoC6Hr0CUOsCY0n46 gzxRV7MJx9yX+LqNr73xaJRNR89PbZR3vMm7wxCkD6iTsST1EtH8U1M441kzqnqFu0tb KoUTGu2MoWc+CopMIkwHQ3UMze4T8kBL4OXTM5N2p+3rRpv52TizCEd4wGi3uwsiogsJ WMMi8Vw4j7IIW/i2Dehft0mEE3lbY9toFmMuCEwYHljJVUnL991VJTVMXE4zPUxqAnlw NeSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729613341; x=1730218141; 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=Rc9fm6Hfw8AXu+RwSaqa1sqHwQrNjY3G32u+RXEGjR0=; b=RvQsH4i5nwMzbmMfe/LbiSQ2XRgrxsuJltsCaLrJb2CqzYFzGFX56/S5lUD11X20wP Ynaf0KBO4WmhWkCATo4hOaPzzwat9KiFqUFcytP68b1fkyk/4ThmJVljDQnqyqPJyKBQ mig0AItbRl4p1719TdiNCyzYWozZkB1AqAJUGC41XCKdxFtDbPzEcyn5bVKkKmMOYRlY q5yvyT9J8x9qennFYEicP2Be5mYO32lUmpicmdrGVMmfCugje5naqmZ13CcSnMMWMIiO I1ObXeo9//Km+BKdn9gjKM4ICRT9RCUW1lVBRu9cYzIeiaBqJyBqpL+d0MCB07fZNojk InRA==
X-Gm-Message-State: AOJu0YzQB4OCBEBbndLuOeB7Qb5tiukDOWnaq1OAetZXdKSNOZsybowc BhOt+MTKDuImCumxZVO+5NEQLku9sdC0dghb90OKiZQNr/9o/rBNNvqKWu9V5CTZrLrtQqPpT+q JOReFMVYaIKfeqsOrGEA6DcGHNnTSRitFN9hyGa1OteeHxMGV57E=
X-Google-Smtp-Source: AGHT+IGYnGJVqbvBcI7L72ekvmN7CKU8n7EB3jEG8GGfQJJJNCxM/T1+4MauAdtmCZXRyRas9AceVsZ8ficKy3wHEo4=
X-Received: by 2002:a05:6402:5243:b0:5cb:615c:a6ca with SMTP id 4fb4d7f45d1cf-5cb615ca6dbmr7984531a12.28.1729613340905; Tue, 22 Oct 2024 09:09:00 -0700 (PDT)
MIME-Version: 1.0
References: <172955108849.2082351.314284588549438876@dt-datatracker-78dc5ccf94-w8wgc> <SN7PR11MB6900E7F8CF85CE671D95A1FCC1432@SN7PR11MB6900.namprd11.prod.outlook.com>
In-Reply-To: <SN7PR11MB6900E7F8CF85CE671D95A1FCC1432@SN7PR11MB6900.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 22 Oct 2024 18:08:49 +0200
Message-ID: <CAOj+MMFVNZNK4k5H1RUHVpNr31gb8f3s5NYG69TR=Z1aCVAVew@mail.gmail.com>
To: "Krishnaswamy Ananthamurthy (kriswamy)" <kriswamy=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c8af33062512fc44"
Message-ID-Hash: EBO7655MSS3QZ67G4UZLDHBLV2PQ4HB7
X-Message-ID-Hash: EBO7655MSS3QZ67G4UZLDHBLV2PQ4HB7
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/y8OxDPzYu2lWwA5XSVmFvJguN7U>
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,

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
>