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

Donatas Abraitis <donatas.abraitis@gmail.com> Wed, 23 October 2024 11:30 UTC

Return-Path: <donatas.abraitis@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 27301C14F6A5 for <idr@ietfa.amsl.com>; Wed, 23 Oct 2024 04:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, 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_BLOCKED=0.001, 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 i-cbqIO6UErI for <idr@ietfa.amsl.com>; Wed, 23 Oct 2024 04:29:58 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 32C07C14F61B for <idr@ietf.org>; Wed, 23 Oct 2024 04:29:58 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-dff1ccdc17bso5824364276.0 for <idr@ietf.org>; Wed, 23 Oct 2024 04:29:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729682997; x=1730287797; 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=Gcv4rOI+6x9Xb0+cUkdnmgFwmdMj8ntfMl4CVsXP07g=; b=VBDwWIRAJuxR2Nxc+2tgAoYWe/Psx/egLCopmlvF58mrV6xaQcaemWt7ZEk3inBaH1 FTAF8W/Y4Zq6psBfxz8NbIvdY3NuKs8IYZeI6pKituzAr2XP+5bQqZ8I/Qkurq9lXlG7 AIzm01hb/V2G7Bp14PvX9pUOi7GJVJQ0OHDTOrT7OcPCk+u4+g19Ivjtk/+yiSmENkYN OZDx/gy3+mhIaWjpwLw8zXW718/HjyhFLWXfct6p3EdMWOSpRe1vQxaCyQcJ0AWF7IYj yyFKFdM7jOXGE2EO1VbMw4Gc7MXyzpNDz3iBhoibEnxcgjbqECkI7K5/wy9ySggsi9g2 f3Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729682997; x=1730287797; 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=Gcv4rOI+6x9Xb0+cUkdnmgFwmdMj8ntfMl4CVsXP07g=; b=VKodaKKwc2V/I/34VJgG7lypkyPhtcR1Yhpxn0g1mHzyD3tFSDQrS6Tzn5mCUj2vcU o/XhjxC5ljOvJcpDRptguxsga8dRdm4KDgais9LhzphtNPNpx5n/uC3trmkvcFQK/bMW nTC7tTBjBiSjS50W1h6POqQ9HiJq9aYJgZy+OB9jCbCJyzKF1LXfAvErpX4ZoZ2EUDhh KhJcMJXOgHcHre9P3poyBamSr15bNlohKhlKZvsfCybkcLVki4uCfXs7Ogs8cN4B0x2t DHyaS6QPO1QXsEjY+SlMNypkPW9fRV3AAE5OZ7JQ40fNQZmm0d40eXd4rYtS1ntIE2gV oTYA==
X-Forwarded-Encrypted: i=1; AJvYcCXD+1FcVSB9g6hqYgHctkubjr9rHGZeymO+GTXIMz5Obit+jOAYPUCXX0fv1pTd9cHnU64=@ietf.org
X-Gm-Message-State: AOJu0YwTfKwEaExOoix+X/f6x4kTix06Ic1eEjoQwitVU6FNQRJAO3nt YG50GU6yhvSX9+Uzgl6ED/z0dlGyhZzWMlFBWV0mLED587tpcnaNeEntLIz68S0CFzToDgUMrkn H1WxSkSwYlDrw92ovCDsfILCoc6Y=
X-Google-Smtp-Source: AGHT+IEOVAqMkeLrlJsLrw8zd/SRHMx62/z1PeTpC8oqZLqeWscH3yP3DJIx9C45zryvaUHZHwQaZv7bZLWkzggIQYI=
X-Received: by 2002:a05:690c:dd3:b0:6dd:cdd7:ce49 with SMTP id 00721157ae682-6e7f0df5d79mr21412387b3.6.1729682997340; Wed, 23 Oct 2024 04:29:57 -0700 (PDT)
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>
In-Reply-To: <CAOj+MMH3sicODQHs38vqvPtkEQYD42NpJOaLTzkJuX2DYMmy9w@mail.gmail.com>
From: Donatas Abraitis <donatas.abraitis@gmail.com>
Date: Wed, 23 Oct 2024 14:29:45 +0300
Message-ID: <CAPF+HwVRf=TMow=Yghr-YZQx_0L=E4m_620yy-3P51U+H98akw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Content-Type: multipart/alternative; boundary="000000000000a176f2062523342f"
Message-ID-Hash: J7BMQPUZWUKUGT3L5Z65A2Z3J2KGDLSF
X-Message-ID-Hash: J7BMQPUZWUKUGT3L5Z65A2Z3J2KGDLSF
X-MailFrom: donatas.abraitis@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: "Krishnaswamy Ananthamurthy (kriswamy)" <kriswamy=40cisco.com@dmarc.ietf.org>, "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/KaUHfKvUuN8Ku5J-04ihYlIeMMs>
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>

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