[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 10:21 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 A285CC1DA2E5 for <idr@ietfa.amsl.com>; Wed, 23 Oct 2024 03:21:11 -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 DORkAWKcBOTn for <idr@ietfa.amsl.com>; Wed, 23 Oct 2024 03:21:07 -0700 (PDT)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (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 BC40DC151538 for <idr@ietf.org>; Wed, 23 Oct 2024 03:21:07 -0700 (PDT)
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-6e34fa656a2so61926797b3.1 for <idr@ietf.org>; Wed, 23 Oct 2024 03:21:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729678867; x=1730283667; 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=gwOE44A6Bs6juM30Zll/bHEAaAY8iGEHyurW5lDj+/0=; b=GbI63kqApv+Xd13zKrhzJlfJs5nIL+Z/WEHFUEqheAaVp3i9u/PQXbks88yfEwwREv 4xpWKSC1DxkscjCYBDSGVIs4euvqL0WTbJ6gEWoFpeWogA2dknj8nNBekk8wOaMUcZNF UkPjytNTGymgkpnDfl8YHyiSrlBHwKKX5drzol0n8ebUoVAUPn2kmwWkds4W6NO3Tlu0 hmZdMgSQK8UUcuNcsXy+OWtGHJ0n2cd3UZe6KVEdErEFIR5P8X0VEO+Er288zAVCJdio VR0B8TpZ4VE5K4egTlsLCTTvW5jQTPYJxjiSRAdiAZwoJ54DXei7WAnpwCPWB870necH HStA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729678867; x=1730283667; 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=gwOE44A6Bs6juM30Zll/bHEAaAY8iGEHyurW5lDj+/0=; b=Uw920+oCcRpwgvL3iFiVSG29OlEDcOGw6Rro4p5hwlrzwjROMLAcqd5LQ8BD5DyCyv kc3yDs6CxLyz4EistpXcZ1GHRHpCfejxKjH4sDU1mcsgm3STvpqAWwmDlmdWXaho+GRN RESKY6oSsmdwG2TdTsZbgxcce48ylKry7I5mkGrGO/HhnOxLm539DTnT2szGhh9C7xnN cGvwa8DDGNmhZhFnj4mmXmmLwsAfzwjSANzQiho3/SajXKUqjWDDNjfCFvZT2B0mlPFF OLFQ+PrdeEWKmyorQthKz/Zyyg6n5dle7h+NMhC5731Xd0Xmp/dAQ/hLaX131g0RuXZY twkQ==
X-Forwarded-Encrypted: i=1; AJvYcCW/UPSta/UBJv6PAwx18iBH9xVCkfpFAKmnajq2xkb6lnlKgBt1cqHdCE2/1e44EkMIIsU=@ietf.org
X-Gm-Message-State: AOJu0YzRhllw8tbKGkL31bzWAIb4EKs3uCgZY+KK55yMtsLFItTgDJwd 5cufHQB3xyq4pza6OpKuVCKm2SWVAOA6pPmpBso6JrJugJOGcXOJmwbve2PrLJ1rUgpVZKtjrUU 6yMpa4ZERiiiM+1Q7NLGNJa0IgJovTNKi
X-Google-Smtp-Source: AGHT+IHFU/ESIz5XOhnaVf6V5yQ4m4YUSGAZLPOuggi42EZAtCOEOQv7SVDxbpf56b7zzaMikETNiPUKZl0UUIaMkwQ=
X-Received: by 2002:a05:690c:6907:b0:6e3:37a7:8a98 with SMTP id 00721157ae682-6e7f0e0537emr20919447b3.14.1729678866758; Wed, 23 Oct 2024 03:21:06 -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>
In-Reply-To: <SN7PR11MB69004C7C1222D4669027970BC14C2@SN7PR11MB6900.namprd11.prod.outlook.com>
From: Donatas Abraitis <donatas.abraitis@gmail.com>
Date: Wed, 23 Oct 2024 13:20:55 +0300
Message-ID: <CAPF+HwVTjiMGct3sNkTtVhWs4OtgCJ5G06vAMvaLdw36hY4+4Q@mail.gmail.com>
To: "Krishnaswamy Ananthamurthy (kriswamy)" <kriswamy=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006dc4f40625223ed7"
Message-ID-Hash: FMKL3GVLGCJ7EVUASRKTZCQKLQ5QYM5D
X-Message-ID-Hash: FMKL3GVLGCJ7EVUASRKTZCQKLQ5QYM5D
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: 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/ooW1_lY-SWwhQLynPyK4bS3VvhE>
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>
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
- [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