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

Robert Raszuk <robert@raszuk.net> Fri, 02 July 2021 12:48 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 71C883A1D6E for <idr@ietfa.amsl.com>; Fri, 2 Jul 2021 05:48:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 86lxscBQU2MQ for <idr@ietfa.amsl.com>; Fri, 2 Jul 2021 05:48:32 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 ADD3D3A1D6C for <idr@ietf.org>; Fri, 2 Jul 2021 05:48:31 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id u20so13080572ljo.12 for <idr@ietf.org>; Fri, 02 Jul 2021 05:48:31 -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=QFaiheldv5WRRIQizw5sMqXEVD0y1+RYbRmL877QyKE=; b=E/LUweZcYgHsV4ppjWvf2wfOeHHeEUF6ypt6Nz8Kj3gIuhsSkpRDpgJ16WfuU/JZDL XNhZ5hcW3xzxU7ONamWwQA7MANk6X5ocdlPkjO5U8mpLKJs36SB47Sm4Mou3TJXxV/WX 7dyHBLsIY3WaF9al7VRjwl4882pKsDP68tILi0fYg8mqb+aGuiiPeHDcQA9cInRxIMcs AM5kW19NpUNs7f1uWsUMMsyzNAWYAdV2pcpd8K2NPD51y1LctmTevFrrlPoGWO9fgNcL C6nJOLLEp6i/bJxQ8sx+ORrObM5mHeiftuH6ScxKuajDWu3hZwHrSl0TgQYAC+NegwPr tRLA==
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=QFaiheldv5WRRIQizw5sMqXEVD0y1+RYbRmL877QyKE=; b=C2midbAFFSGvleRPi8q+zsT4RllP3d6op1MxDquxjxClsXrrlZNTnF9/8w4plkO9VW /IrvF2A3C8Uyb+cQHD6pqivykMe+0nYz8L7FPQpZ4w1o3z22R1xpkDXwvcEXSgbuVukE AZCKiApL3byBW8K7B6qTsMg+vSSAop6hM7nY2yMBR81z7ji/3DqVvr0LUNAU4Jv1ILHi 1uSfg9icTwUKTrMma+YF30718pXK68lKJynpUWMFifMM+booCf4ocn5NrTGnb8oTp++t wpWwcp0ACFJyCK0hEZl00i3MmHUzAW8Cfgg+PbBQHll7ZxFx85+h6VZffTFO7Jjnj8AU jw7g==
X-Gm-Message-State: AOAM53244qditFpe2nwGbr99h2IJ1g8HWIct5s8FK8vtufStTyqUO2U3 HeGjMqlyJ4zC6d/+nZRmwxghy2/mm/XNIaetwH09Lg==
X-Google-Smtp-Source: ABdhPJxoSqlG6+IMri7VGcIDjHBtE7EXdp20yX7r2HhPvAv7pKWZ3PdOCfn86xhyecUXpJWnt18g3in6GsQ2Jc+z4fI=
X-Received: by 2002:a2e:a486:: with SMTP id h6mr3677355lji.321.1625230107790; Fri, 02 Jul 2021 05:48:27 -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> <CAOj+MMGB8YXnq7AO2xP9GfVq1swe_DPW3oZAG4icvBtV=Ej-8g@mail.gmail.com> <499C4FC1-B383-4E18-9661-6AC0F4345080@cisco.com>
In-Reply-To: <499C4FC1-B383-4E18-9661-6AC0F4345080@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 2 Jul 2021 14:48:17 +0200
Message-ID: <CAOj+MMFQtHRRdVqvMemGnUWguhmj6vcVxyYeiLwgzi3hE49GRQ@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="00000000000040e0d405c6235f4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/raNuXzWp1G4Qx7rnQykEVBe4O-U>
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 12:48:38 -0000

Jakob,

> On Fri, Jul 2, 2021 at 1:32 PM Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> The difficulty with that is that IBGP and EBGP also have an admin-distance
> and the admin-distance of those routes is not used and cannot be used in
> the best path tie breaker.
>

I think it really does not matter (yes originally I was also asking to
myself the same question).

Reason why this does not matter is that ebgp vs ibgp comparison is much
further in best path selection then local pref.

So BGP will overall select the best and push it to the RIB. Of course for
this entire scheme to work BGP now has to lie and neither say this is EBGP
not IBGP learned route but say use new admin distance 0.5 :)  Otherwise
static will overwrite any BGP produced route in RIB which is not what we
want in the first place.

Thx,
R.

On Jul 2, 2021, at 1:13 AM, Robert Raszuk <robert@raszuk.net> wrote:
>
> 
>
> > 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.
>>
>