From nobody Fri Jul 2 01:12:47 2021 Return-Path: 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 ; 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 ; 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 ; Fri, 2 Jul 2021 01:12:38 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id f13so12173098ljp.10 for ; 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: In-Reply-To: From: Robert Raszuk Date: Fri, 2 Jul 2021 10:12:24 +0200 Message-ID: To: "Jakob Heitz (jheitz)" Cc: Gyan Mishra , "idr@ietf. org" , Jenny Yuan , Enke Chen Content-Type: multipart/alternative; boundary="000000000000a7b75005c61f84cf" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 08:12:45 -0000 --000000000000a7b75005c61f84cf Content-Type: text/plain; charset="UTF-8" > 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) 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. > --000000000000a7b75005c61f84cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> The draft = addresses the=C2=A0different outcome if BGP learns the route=C2=A0

> firs= t from it peer or learns=C2=A0it first from the local RIB.

=

Yes that = is section 2.1=C2=A0


However, more interesting to me= is the scenario described in section 2.2 - Network-wide Behavior=C2=A0 - n= o local peers.=C2=A0


Here by setting AD on a per rou= te basis and propagating it via IBGP using=C2=A0Local Preference we get con= sistent active-backup network wide.=C2=A0


Thx,

R.


=

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

A= dmin-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.

I= n both of these implementations, RIB and BGP are separate processes<= u>

w= ith separate memory spaces and their own routing tables.

R= outes are passed between them using inter-process communication messages.

T= hey cannot access each other's routing tables. Other routing protoclos,=

s= uch as OSPF, ISIS and static are also separate processes. Each of the routi= ng

p= rotocols downloads their valid routes to RIB. If the same IP prefix is

s= ent to RIB by multiple routing protocols, RIB will select one to be used=

f= or forwarding and resolving nexthops. RIB uses admin-distance to decide.=

R= outing protocols get their local routes from RIB.

<= u>=C2=A0

A= static route has admin-distance of 1 by default.

H= owever, a static route can be configured with a different admin-distance.

I= t is possible to configure a backup static route by configuring a high

a= dmin-distance for it.

I= n that case, if another route is found for the given prefix by another

r= outing protocol, say an ISIS route, then the ISIS route will be used=

f= or forwarding. Only if the ISIS route disappears will the backup static<= /u>

r= oute be used.

<= u>=C2=A0

N= ow, suppose we want to advertise that prefix in BGP. We can do that<= u>

w= ith a "redistribute" statement or with a "network" stat= ement.

T= hey work a little bit differently, but either command will import=

t= he route from the RIB into BGP.

O= nce the route is in BGP, it loses its admin-distance.<= /p>

B= GP has no knowledge of the admin-distance that this route had in RIB.

T= here is no admin-distance in section 9.1 of RFC 4271.<= /p>

T= his is the root of the problem that Enke and Jenny are trying to solve.<= /u>

<= u>=C2=A0

T= he 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<= /u>

d= ifferent outcome if BGP learns the route first from it peer or learns

i= t first from the local RIB.

<= u>=C2=A0

R= egards,

J= akob.

--000000000000a7b75005c61f84cf--