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

Gyan Mishra <hayabusagsm@gmail.com> Thu, 01 July 2021 18:02 UTC

Return-Path: <hayabusagsm@gmail.com>
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 F3A123A12C4 for <idr@ietfa.amsl.com>; Thu, 1 Jul 2021 11:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nRf1rfW15qY1 for <idr@ietfa.amsl.com>; Thu, 1 Jul 2021 11:02:37 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 D288C3A12C1 for <idr@ietf.org>; Thu, 1 Jul 2021 11:02:37 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id b5so4107907plg.2 for <idr@ietf.org>; Thu, 01 Jul 2021 11:02:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=duF46d7flGreCdLGceaXvS8JD2fKh2ZItpZ8MQoHsE8=; b=nIAeFzPS63Xb0rwUtTIF1/VNB87QUaO/HPKDGAcdERxo1mLM/SS5KH5ukOJXUi4boK PM70HkmJYmTP3qZOpp9pl+7n0tKVXf5VaNaV+/EBp9wSQQD85JQd7z8Lrm8gMXmFl1CA FKZdNbGxL+TQkq51BvgidBM+aL+8Qtao0R+8n3RLEY5uHbYMiWKgG2LcLdutHtkbGUML EXnq1jVjfKeLP89C8MQZ8Tdg2osURXeHaXzT6jnmtUsRMv8aXyrQsMecf1j5V+Jm36mY fpewyahUYA6prC45aWjAFq5QXsozSjk8DISD2z8c3oO++m+FyGXihCQmvIXO1XmqzX6v H49g==
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=duF46d7flGreCdLGceaXvS8JD2fKh2ZItpZ8MQoHsE8=; b=ufE6CKSaIAhd3rpZkac/YLcFJCw3D5CEUaxlRLFBfeIEJ9LQLaTYL6dl/BpfVvtFlN Rij5Tpe7dmrYhuPNJT7xvxNoaNEpxTnaaiCd2ox1YfBbDNVnRIWG1sOmdjwHT1TlqnGj rId3NpYJ+4g7W6ZRrdpAdxODOWPWlfuFvaux67uxzmcuSzGZLAi2CZPXdSoHSuiRrJIP X2UqJmxAmdCUSzXn8C+0qKgUebt1rveOyxjVyo31jN4GkTZ9GdZ17kIqeVcqS0x0a1t8 OGGCYVOBMpn2nnIa15/OeGfC4oDxUbo1Vuj/ES0IOctZUBdoIC1VVETiKZqiU+BwK2xX tRPw==
X-Gm-Message-State: AOAM533Ytsa3KkxHYM0sSeY2kyW9KSpl+JTOEq2UPHMQlA/prNcm6pLq CPpFY6DeK6cgi1DGZwBK3Fo8NMVcXoklPMD9XAY=
X-Google-Smtp-Source: ABdhPJw+Uk2qKzitV8Y/zazytd16zNx9mynt850bADOwq82k+Lx0sJ6xr3KskpnmXXF/bTt7L3xe82uGEyuoU1dpcqI=
X-Received: by 2002:a17:902:7d8a:b029:115:77ae:e1dd with SMTP id a10-20020a1709027d8ab029011577aee1ddmr966768plm.50.1625162556396; Thu, 01 Jul 2021 11:02:36 -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>
In-Reply-To: <CANJ8pZ9Und3fF324tzTAkhrMFV0MZfhHYfZussiYSCNUx-n_Hw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 01 Jul 2021 14:02:25 -0400
Message-ID: <CABNhwV3BXk=+fuxVSg_9j+u+5Ffr+NQGE9P75NCPpTaUr5LqYQ@mail.gmail.com>
To: Enke Chen <enchen@paloaltonetworks.com>
Cc: Jenny Yuan <jyuan@paloaltonetworks.com>, Robert Raszuk <robert@raszuk.net>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e057e305c613a4b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XhY4KLaGKA5q5eQ37rt7V1KAHDU>
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 18:02:44 -0000

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*