Re: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-04.txt

Robert Raszuk <robert@raszuk.net> Tue, 05 March 2024 10:32 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 D1EC3C14F696 for <idr@ietfa.amsl.com>; Tue, 5 Mar 2024 02:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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 b4IA8PEzoW_e for <idr@ietfa.amsl.com>; Tue, 5 Mar 2024 02:32:44 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B2BC14F68B for <idr@ietf.org>; Tue, 5 Mar 2024 02:32:43 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-56454c695e6so9100583a12.0 for <idr@ietf.org>; Tue, 05 Mar 2024 02:32:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1709634762; x=1710239562; 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=Yb7ypRJ9ucZLPVVpEeA4FoMyv1vR/tD53xeRzimMN+E=; b=ZbWIFmZ8en3Po80i+4q/IpYpHZl0hnMPWnvvm72zoX0iYKZKxoy9RRVGh6orzzckCa 3ZlbFqLIesWiLwFUUKbo7AoLB39TENSj0yEqmGkQv8tTw2W0z2Gwk2cglgvmfzZXXFxy pNKUaREe7DkhjJxQ6CuBpZDKb6IdCs+YXDARDDyl6NiktY37cXDJ9Chf8JCs+UuL+m9G dSd03vdPdn/CwaLiCLFWnavpoX++XFV3/acv1As7iq4t8IT7UKicahW+U4nYvsCirFBY GGDnnMoTqcX46gOIGAqhu/SZ4GyhJ5vYph0z60dtAgwBmHBipNBO1o0S0grs4Fk7AHM/ Ga7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709634762; x=1710239562; 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=Yb7ypRJ9ucZLPVVpEeA4FoMyv1vR/tD53xeRzimMN+E=; b=BoiOoCmYDauD42iRD4DAIPOBs+LfTMoRCDdpLRxqsfkKr0YuT+nFsHweJ2Qz+rYcn9 RvxymQIKiNMQa8fHxj2AtTEl9EDCOdCKhidYBpuO4XXtq6M1TiBMB7nyzrwHy+NFmq8O yH8LPVKkT1ThHi2E9Ez4FcZLCKyobOtT4lwOrg1RV3wgpWNxq814nXA4kUTwiuzqt14T hhA+Ti7z31N+Tgh0FMWPcolh2nLoX2WQZNT/7tom2Xfv2G8qEMbV7qCu79zADuICqBAl TudQfCVrDeYXAARMHSGXKJlGxmEbjV83+cOhN28069f2GYJVmI64foCLzk16bAYm9X9b 1iRw==
X-Gm-Message-State: AOJu0YwwZ9h54LNNQHpTnWBVIsnB7n8samLraMkSkdgGld+yroqqOCiY tm/HUDBfpnBdKOi5AefluyeekgrM3nGm/ldfSU5KNSBMV73WpaWnJyeNQSWtzdFOby0R5TspnEE 4D2WRy7c3vS6kC8g6e1H0rPPEjjh3KBluqXQid0Ecw9VMD6+jUY0=
X-Google-Smtp-Source: AGHT+IE4dpzVRlS0/9cJOkbl3JcgtxFyqtfHkFFfwc+vl2Ofhl5mWUUxXR/Z6I6aHR2fM9DEOg2mfF5ctChz2fRh55o=
X-Received: by 2002:a50:85c3:0:b0:566:5cd2:873 with SMTP id q3-20020a5085c3000000b005665cd20873mr2390105edh.4.1709634762191; Tue, 05 Mar 2024 02:32:42 -0800 (PST)
MIME-Version: 1.0
References: <170954803408.43395.8450424120941872596@ietfa.amsl.com> <60B94E98-3D0E-44CF-8521-96A0F217AFDA@gmail.com> <CAOj+MMH7PrQGaZ__-ZGnEmvkZWT38xuaP+fhraUtJ4C=iK=Thw@mail.gmail.com> <667F1B5D-68AC-410C-B490-5DD020B8D5E0@gmail.com>
In-Reply-To: <667F1B5D-68AC-410C-B490-5DD020B8D5E0@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 05 Mar 2024 11:32:30 +0100
Message-ID: <CAOj+MMHTmvXqgLmJtkOZcb-ZF-3T7UZpbaaCmys2kw7eEtwS7w@mail.gmail.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Cc: IDR List <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b24da90612e75c7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XV97VKu7SJ7py2HA15Rr4dgMKoo>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-04.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2024 10:32:47 -0000

Hi Alex,

I am not actually aware of implementations supporting best external on IBGP
per this paragraph:

*Quote
from https://datatracker.ietf.org/doc/html/draft-ietf-idr-best-external
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-best-external>*


*When selecting the path to add to the Adj-RIB-OUT, this document specifies
that the path that originate from the same mesh MAY be excluded from
consideration.  This results in an Adj-RIB-OUT selection per mesh (the set
of non-client peers or a specific cluster).*

But you are right that this will/would address the issue. In fact our draft
is pretty much proposing the very same as the second option:

*Quote
from https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-hierarchical-rr
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-hierarchical-rr>*

*When advertising an RT membership NLRI to a route-reflector peer (either
client or non-client), if the best path as selected by the path selection
procedure described in Section 9.1 of [RFC4271] is the path received from
this peer, and there are alternative paths received from other peers, then
the most disjoint alternative route SHOULD be advertised to this peer. The
most disjoint alternative path is the path whose CLUSTER_LIST and
ORIGINATOR_ID attributes are diverse from the attributes of the best path.*

Except we specify this further and include not only different mesh criteria
but also ORIGINATOR_ID difference when selecting a different path.

Many thx,
Robert


On Tue, Mar 5, 2024 at 11:09 AM Alexander Okonnikov <
alexander.okonnikov@gmail.com> wrote:

> Hi Robert,
>
> Yes, initially 'best external' addressed eBGP, but later it was
> generalized for RR clusters as well.
>
> BR
> Alexander Okonnikov
>
> 5 марта 2024 г., в 12:53, Robert Raszuk <robert@raszuk.net> написал(а):
>
> Alex,
>
> The draft applies to reflected IBGP routes.
>
> Best external draft you are quoting - which is extremely useful and
> deployed proposal - is applicable to ASBRs/PEs learning BGP routes over
> EBGP.
>
> Thx,
> R.
>
>
>
> On Tue, Mar 5, 2024 at 10:45 AM Alexander Okonnikov <
> alexander.okonnikov@gmail.com> wrote:
>
>> Hi authors,
>>
>> We have already more generic alternative for the second solution - 'Best
>> external route' described in
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-best-external-05.
>> What about choosing one of two solutions - I lean towards 'best external'
>> based solution. It seems lightweight and doesn't require Add-paths support.
>>
>> Thanks.
>>
>> BR
>> Alexander Okonnikov
>>
>> 4 марта 2024 г., в 13:27, internet-drafts@ietf.org написал(а):
>>
>> Internet-Draft draft-ietf-idr-rtc-hierarchical-rr-04.txt is now
>> available. It
>> is a work item of the Inter-Domain Routing (IDR) WG of the IETF.
>>
>>   Title:   Extensions to RT-Constrain in Hierarchical Route Reflection
>> Scenarios
>>   Authors: Jie Dong
>>            Mach(Guoyi) Chen
>>            Robert Raszuk
>>   Name:    draft-ietf-idr-rtc-hierarchical-rr-04.txt
>>   Pages:   6
>>   Dates:   2024-03-04
>>
>> Abstract:
>>
>>   The Route Target (RT) Constrain mechanism specified in RFC 4684 is
>>   used to build a route distribution graph in order to restrict the
>>   propagation of Virtual Private Network (VPN) routes.  In network
>>   scenarios where hierarchical route reflection (RR) is used, the
>>   existing RT-Constrain mechanism cannot guarantee a correct route
>>   distribution graph.  This document describes the problem scenario and
>>   proposes a solution to address the RT-Constrain issue in hierarchical
>>   RR scenarios.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/
>>
>> There is also an HTMLized version available at:
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-hierarchical-rr-04
>>
>> A diff from the previous version is available at:
>>
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-rtc-hierarchical-rr-04
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>