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

Robert Raszuk <robert@raszuk.net> Thu, 01 July 2021 20:50 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 44BF23A1C83 for <idr@ietfa.amsl.com>; Thu, 1 Jul 2021 13:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTTPS_HTTP_MISMATCH=0.1, 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 m5v2CZ9xnpEc for <idr@ietfa.amsl.com>; Thu, 1 Jul 2021 13:50:39 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4ECF33A1C82 for <idr@ietf.org>; Thu, 1 Jul 2021 13:50:38 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id a11so14122419lfg.11 for <idr@ietf.org>; Thu, 01 Jul 2021 13:50: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=vMDEUbTgTybTESoVhppoAc+hvaKKbnOC7EhfOMnjUGw=; b=NJNwZ0A1feYpkahY7LP95p2sJO8DkDTbmiKb2tn2v/reFtoXvcqcEYK/31xnOwFcmh 7ImrAwnBiArl7LVEmmEsmGDYvc59K6Qn3+yAtp8tRD7CCXvEA2e6J0pXzRtlL76oe6LX TUxbS9KWVrD8MhQeZaOzZL3BPUf4hBlu8QuqYectTAwGfmNp+kT56k/IgTqScItnGmCC 73GU0B/HjzgG9RFVJX463AkCT232hERMlqhR9s6/VjzGmQDlWHDjonoV2GcCrvJ0dSQI 2FQYkwh8Rgpai8JuAV6lFXUV6KKM8H0pL/iqszHa45qiURwwhZS/KPX92nYqRyatb98s 4zaQ==
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=vMDEUbTgTybTESoVhppoAc+hvaKKbnOC7EhfOMnjUGw=; b=FOkl2eX0dHg4Jy//QfkU9fzloMVsWCuOmorOWgnjN1yvTOggSK/kCsP8eovYBA3bnj RB3IlrYLBnzhfCGtycc9bm3sU0iMguSroNBkQDjJF+hxhJnHLeCnBzIHUiQ2EYYMNOaq pZE1MCz72toTnptM2cnKEheFj8jRrULFu1aRggSPZe19zABYNiQUuOgohXNVhz0IcHt0 8IsJEFA/po13A/sG/aGl2IgxIhslMOc16PX9aMQajNXLKHHJdfI9Z6Fnh+l80b8mDE1c MzbyuGm5irx/bf4WG+oQ0ZV4jzLfrZv/ga+Rd+cWWwmLjG2Z8uGvhH5/r/QN2jawcAF6 YRCg==
X-Gm-Message-State: AOAM532J6LxnHijON32Yg9sLuIXM1HCQkliKmLkCQs1FCpiCH5aljdhu 3l6p5xkLpF0EDaiMxd+Kitg9dSkTixYlMCoRI+x26w==
X-Google-Smtp-Source: ABdhPJwEuG83Kyyv4goi+QQQC3C5aJePmkwZlr8LVYgE/aD1f1c2KlRwmmkxH9ENvtw3UluJByNp1MDY90AuJPE5Jtg=
X-Received: by 2002:a19:ef0e:: with SMTP id n14mr1121983lfh.36.1625172634943; Thu, 01 Jul 2021 13:50:34 -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> <CAH1iCirqM8wB7AhiGRJdwxLsxMoRFrB-UebU6xhpyjZ87btezw@mail.gmail.com>
In-Reply-To: <CAH1iCirqM8wB7AhiGRJdwxLsxMoRFrB-UebU6xhpyjZ87btezw@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 01 Jul 2021 22:50:24 +0200
Message-ID: <CAOj+MMGtnZtJjEAWAT+BhdnQCArbUsDBn9kYZy0Pqjd+Pjp94g@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, "idr@ietf. org" <idr@ietf.org>, Jenny Yuan <jyuan@paloaltonetworks.com>
Content-Type: multipart/related; boundary="0000000000009b5e7905c615fd7d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HmRDplC4TPOtxhial-BN3wRE1bc>
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: Thu, 01 Jul 2021 20:50:44 -0000

Brian,

In general you are correct that BGP would be much better if it would
only carry originated (somewhere) prefixes.

However the reality is that you have customers hanging off your network
with static routes or ospf. Even worse some of those customers got recently
fancy and they are multihomed what makes dynamic routing quite useful
to/from such sites.

So you can either put those customer prefixes to BGP or carry it with your
say separate IGP instance. You could also just put them into controller and
only deal with end to end encapsulations to get ingress to egress packets
via your network.

Well people like simplicity so just put those into BGP then aggregate it
(especially if those chucks are coming out of ones space).

This draft is trying to help with this in situations where you have
requirement for active-backup somehow predictable path selection.

Best,
Robert.



On Thu, Jul 1, 2021 at 10:41 PM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

> Top-reply, sorry if anyone doesn't like that.
>
> So, serious question:
> What if the solution to this problem is simply, "do not redistribute
> anything into BGP"?
> (If that is the case, maybe changing this draft to say that and nothing
> else is the best approach?)
>
> Specifically, instead of doing any redistributes, configure a prefix as
> locally originated (in cisco-speak, "network" within a BGP config section,
> IIRC).
> The BGP rules would result in it being announced into BGP if and only if
> it is (and only while it continues to be) resolvable (i.e. has a next hop
> in the RIB, I believe.)
>
> Does this actually fix the problem?
> (I have never liked redistribution, as it leads to a lot of funky
> behavior, including extraneous update messages that pollute the global BGP
> DFZ.)
>
> Brian
>
> On Thu, Jul 1, 2021 at 11:55 AM Robert Raszuk <robert@raszuk.net> wrote:
>
>> Gyan,
>>
>> > My understanding is by default most all implementations that I know of
>> for example Cisco & Juniper which have use identical default AD
>>
>> Can you provide source(s) of your above information ?
>>
>> To the best of my knowledge they are quite different ...
>>
>> Cisco:
>>
>> [image: image.png]
>>
>> Juniper:
>>
>> [image: image.png]
>>
>> Except connected I do not see much of "identical default AD"
>>
>> And that is as the draft says especially important when your intention is
>> to control active - backup paths for a given net.
>>
>> Thx,
>> R.
>>
>>
>> On Thu, Jul 1, 2021 at 8:02 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>>
>>>
>>> Hi Enke
>>>
>>> My understanding is by default most all implementations that I know of
>>> for example Cisco & Juniper which have use identical default AD,
>>> redistribution of the route only occurs from the source protocol that is
>>> being redistributed for example static versus OSPF or ISIS based on AD.
>>>
>>> So if you have multiple protocols redistribution into BGP, the source
>>> protocol with the lowest AD is what is inserted into the default RIB/FIB
>>> and its that specific route from the source protocol that is redistributed
>>> into BGP.   All implementations that I know of work that way.
>>>
>>> I don’t see any issue with deterministic redistribution as exists today
>>> with implementations.
>>>
>>> Normally you are only running one IGP but let’s say you are running OSPF
>>> and ISIS and you have a Juniper and Cisco ASBR redistribution into BGP, as
>>> OSPF has default AD 110, the OSPF prefix would be inserted into the Default
>>> RIB and redistributed into BGP.  Let’s say you set AD for ISIS down to 90
>>> and now the ISIS route is inserted into the RIB and now both Juniper and
>>> Cisco ASBR Will redistribute the ISIS route into BGP.
>>>
>>> I am not seeing the issue that you are trying to solve.
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>> On Wed, Jun 30, 2021 at 3:19 AM Enke Chen <enchen@paloaltonetworks.com>
>>> wrote:
>>>
>>>> Hi, Robert:
>>>>
>>>> 1) Usually the default admin-distance is configurable. Having the same
>>>> admin-distance across implementations would certainly make things simpler,
>>>> but that is not required. What matters is the local_pref value for the
>>>> redistribute backup route:
>>>>
>>>>             local_pref = default_local_pref - delta;
>>>>
>>>> It needs to be in the right order (relatively) for the "role" the route
>>>> is supposed to play.
>>>>
>>>> It's a good question. We will try to clarify it in the next revision.
>>>>
>>>> 2) Certainly it would work if we define the "delta" (or "local_pref")
>>>> for the redistributed route based on its role (e.g., primary, secondary,
>>>> tertiary). But extra config would be needed for specifying the "role".  The
>>>> algorithm described in the draft does not require additional config other
>>>> than the existing "admin-distance".  When more than two paths are involved
>>>> in a multi-vendor environment, the admin-distance needs to be carefully
>>>> assigned in order to get the desired local_pref value.
>>>>
>>>> Thanks.   -- Enke
>>>>
>>>> On Tue, Jun 29, 2021 at 1:05 PM Robert Raszuk <robert@raszuk.net>
>>>> wrote:
>>>>
>>>>> Hi Enke,
>>>>>
>>>>> How do you assure that admin distance is the same or delta would be
>>>>> the same across implementations ?
>>>>>
>>>>> Looking at say junos I see quite different values then when comparing
>>>>> with other implementations ...
>>>>>
>>>>>
>>>>> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-default-route-preference-values.html
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junos_topics_reference_general_routing-2Dprotocols-2Ddefault-2Droute-2Dpreference-2Dvalues.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=GOhXjwEf1z0GAfIQVgVAc4sHvcAog6czTO30VhKwzQk&e=>
>>>>>
>>>>> Would it be simpler to define here verbatim what the local pref should
>>>>> be for redistributed routes ? Then at least those could be used as default
>>>>> local pref values unless overwritten by operator's policy during
>>>>> redistribution.
>>>>>
>>>>> Thx,
>>>>> Robert
>>>>>
>>>>>
>>>>> On Tue, Jun 29, 2021 at 7:14 PM Enke Chen <enchen@paloaltonetworks.com>
>>>>> wrote:
>>>>>
>>>>>> Hi, Folks:
>>>>>>
>>>>>> Apologies for the very long delay in updating the draft:
>>>>>>
>>>>>>        https://datatracker.ietf.org/doc/draft-chen-bgp-redist/01/
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dchen-2Dbgp-2Dredist_01_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=IBn3kTJmGrWISvSq8L3M9GLLamXIqw7t2PvEdtvhmos&e=>
>>>>>>
>>>>>> The issue still exists, and shows up from time to time. The revised
>>>>>> version provides a complete solution that covers the use cases involving a
>>>>>> single router as well as multiple routers in a network.
>>>>>>
>>>>>> Your review and comments are welcome.
>>>>>>
>>>>>> Thanks.   -- Enke
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Idr mailing list
>>>>>> Idr@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=O1wpTf7XmDmE4-mQGDJ9YNEx2UVZW-k1meY3fd-tQrE&e=>
>>>>>>
>>>>> _______________________________________________
>>>> Idr mailing list
>>>> Idr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>>
>>>
>>>
>>> *M 301 502-1347*
>>>
>>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>