Re: [Idr] draft-chen-bgp-redist-01.txt

Robert Raszuk <robert@raszuk.net> Fri, 02 July 2021 08:12 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 C5DAE3A13AE for <idr@ietfa.amsl.com>; Fri, 2 Jul 2021 01:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKLtjMivRGAm for <idr@ietfa.amsl.com>; Fri, 2 Jul 2021 01:12:39 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428F73A13AB for <idr@ietf.org>; Fri, 2 Jul 2021 01:12:38 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id f13so12173098ljp.10 for <idr@ietf.org>; Fri, 02 Jul 2021 01:12:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1WDO1AFFuIfVYruHqYaw7tKndQtiVmh1/IjaQ0SdDS4=; b=IVgWVHc3n3lGaLO+nb+uka5Bl1Ynkxp+hiHn3IGE84dUw0w/iYTzTP7/QARTbqw6Yn /eDvhBjIl4GPZsGEHI7TDg2jWtgP4vvBv0j36jCVeRwNqDVsV9Rp+GteknBK9vsQ4W8N L8aTgoLjfy25HoMg+RviigeQ7miMdU9YNKPkvhwD6VcP90vnnbzH7R+ZOkOjYBTwEkOw uPmo8CEbpqcfmbE5T3eW7LxLkDzE2FN15u1VC+dId3sadu1Zbd3SK2A6z7le+ZhDQkei Sl1XhwqZkACQA59PEk2JwEveQUxiM+T//6KERGALppWczKa5z/ukEf2k9VQxGVtjSos1 22pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1WDO1AFFuIfVYruHqYaw7tKndQtiVmh1/IjaQ0SdDS4=; b=pHQ+uXnCJg/PxH4/5rg/ugLbZmp/9wqEih07OwMz1CwSCxAYWqa6U2o31GxfEApU5S 3bygUTO6vUjFd5J4mmeK2OCdAd1Ffbcmj4+uKPZzdxWGUbjSyeOgJ1ysM5ss7qrxw0AF PtSIhDUc5ESAyDkZjB/aPiX+mwhp8vnVvzwxNpfKMCkudke9O5kggjz30XZqWt2dY1vD bGCXV3C5nQK8s3CuMOSTYg9VZ0euPP7StwmPXUMKBq5lSL6FPuqa2ZmYk6Ad52AYRCh5 XA7UnB6fwvboK024NSWsKnsjnPkf04AvMAN05NJi+qP88dnRDI9wji0tcbZWYRdnysqe hBmw==
X-Gm-Message-State: AOAM5339ZCJy1uO9gRv4FtHJ4+2NN1eIUqvgJ637iQ4n7NLSKRIAssXs m/kVdehrE7DI9/4RqN3IuVdeloVAtxVAqSM55wM6OA==
X-Google-Smtp-Source: ABdhPJz1DjQTo87XaIDJ+B55OmTxbbq0hgoOkmt4lm6zs+ouYPjTsreCivHJukKi3QFlM4QXIWTqDDauYeTCQ90vWfk=
X-Received: by 2002:a2e:5c42:: with SMTP id q63mr2819934ljb.23.1625213555417; Fri, 02 Jul 2021 01:12:35 -0700 (PDT)
MIME-Version: 1.0
References: <CANJ8pZ_2yk666tSca818-e0YdziKjK3dMqhopOtYAP3vKXTEmQ@mail.gmail.com> <CAOj+MME5zZeZDnhpfivbdKj00JwBzi9rjMmzBXxE_fFqkxEVpA@mail.gmail.com> <CANJ8pZ9Und3fF324tzTAkhrMFV0MZfhHYfZussiYSCNUx-n_Hw@mail.gmail.com> <CABNhwV3BXk=+fuxVSg_9j+u+5Ffr+NQGE9P75NCPpTaUr5LqYQ@mail.gmail.com> <CAOj+MMFxM_yvrPDEyQ+dpO7ZxoiQKa0DE4ZQf763Cuidj76QXg@mail.gmail.com> <CABNhwV1q-H1pSypWCvA9VKXBZZTfM3nQNPktjbmbN0D=VSXpBw@mail.gmail.com> <CABNhwV29-t-N6EMmJQzOairgTB5jsPX1h6Q0e+akEgiA2cUpQg@mail.gmail.com> <CABNhwV1QAR8qHdP+rSTOk3eRU5A5tMAfWFFyqXYPQteHtoNyBg@mail.gmail.com> <BYAPR11MB3207B8AE524F71ED25590B94C01F9@BYAPR11MB3207.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3207B8AE524F71ED25590B94C01F9@BYAPR11MB3207.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 2 Jul 2021 10:12:24 +0200
Message-ID: <CAOj+MMGB8YXnq7AO2xP9GfVq1swe_DPW3oZAG4icvBtV=Ej-8g@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, "idr@ietf. org" <idr@ietf.org>, Jenny Yuan <jyuan@paloaltonetworks.com>, Enke Chen <enchen@paloaltonetworks.com>
Content-Type: multipart/alternative; boundary="000000000000a7b75005c61f84cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IDUOR90OdbLaFoNoZZnhPLdmA7k>
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 02 Jul 2021 08:12:45 -0000

> The draft addresses the different outcome if BGP learns the route

> first from it peer or learns it first from the local RIB.


Yes that is section 2.1


However, more interesting to me is the scenario described in section 2.2 -
Network-wide Behavior  - no local peers.


Here by setting AD on a per route basis and propagating it via IBGP
using Local Preference we get consistent active-backup network wide.


Thx,

R.




On Fri, Jul 2, 2021 at 8:33 AM Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> Admin-distance is not defined in any RFCs. It is a vendor only concept.
>
> I can speak about it from the Cisco IOS-XR and Redback perspective.
>
> In both of these implementations, RIB and BGP are separate processes
>
> with separate memory spaces and their own routing tables.
>
> Routes are passed between them using inter-process communication messages.
>
> They cannot access each other's routing tables. Other routing protoclos,
>
> such as OSPF, ISIS and static are also separate processes. Each of the
> routing
>
> protocols downloads their valid routes to RIB. If the same IP prefix is
>
> sent to RIB by multiple routing protocols, RIB will select one to be used
>
> for forwarding and resolving nexthops. RIB uses admin-distance to decide.
>
> Routing protocols get their local routes from RIB.
>
>
>
> A static route has admin-distance of 1 by default.
>
> However, a static route can be configured with a different admin-distance.
>
> It is possible to configure a backup static route by configuring a high
>
> admin-distance for it.
>
> In that case, if another route is found for the given prefix by another
>
> routing protocol, say an ISIS route, then the ISIS route will be used
>
> for forwarding. Only if the ISIS route disappears will the backup static
>
> route be used.
>
>
>
> Now, suppose we want to advertise that prefix in BGP. We can do that
>
> with a "redistribute" statement or with a "network" statement.
>
> They work a little bit differently, but either command will import
>
> the route from the RIB into BGP.
>
> Once the route is in BGP, it loses its admin-distance.
>
> BGP has no knowledge of the admin-distance that this route had in RIB.
>
> There is no admin-distance in section 9.1 of RFC 4271.
>
> This is the root of the problem that Enke and Jenny are trying to solve.
>
>
>
> The problem occurs if the same prefix can be learnt by BGP from
>
> a BGP peer. BGP may download it into RIB. The draft addresses the
>
> different outcome if BGP learns the route first from it peer or learns
>
> it first from the local RIB.
>
>
>
> Regards,
>
> Jakob.
>