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

Robert Raszuk <robert@raszuk.net> Thu, 01 July 2021 18:55 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 68C913A1625 for <idr@ietfa.amsl.com>; Thu, 1 Jul 2021 11:55:00 -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 9EzH7karj2qJ for <idr@ietfa.amsl.com>; Thu, 1 Jul 2021 11:54:55 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 8C5253A1623 for <idr@ietf.org>; Thu, 1 Jul 2021 11:54:54 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id k8so9872507lja.4 for <idr@ietf.org>; Thu, 01 Jul 2021 11:54:54 -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=AIr64jHVt9WYblpUif+OZo9NqygAWbfYQKW495BOGcM=; b=d1EDXp/Pfn5hBXFJNRBEd//y8q75GJps5wZ9j2xLmAZIq3YO54AMkPtUvPSTqZAqNM jC7H8SIq6XcwXe4mr+cpqq+16lmpvfYmGyQqnBpPVGzOGqC5GT3+tJznEATW/6be+yI2 jfHYOSSBIyFAk9bc19/vqsAOj+j9sR1sQaetcWnYFHtbBKmVAVn3ZbODNXkmJ92eJRgf Xuz6C4NuhezWJju07VOWylfdvXLRNPve7pQEdb923kynsCE9yR4e9MPikPcnVy9MzRDU N/3ivklr+IB6K4WgkSC1CDOsV1Abm/XAtfFyT+S4tcN3uQ1KJvOGBXNG7WTxm9083pEq AxQg==
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=AIr64jHVt9WYblpUif+OZo9NqygAWbfYQKW495BOGcM=; b=MV+4UNx/5QEV81y14nCy3VKku0TiJk+gIjDgMMBjjptxNJopLYw6bVbH7HQvOOjR4r ibSWnWD7veCrzeqSB0aX01TaF10fSdlQoPfCj19iBA8kJvwY/0ydePC3SAk0AEp614BW BWzkiRv5P/KUwcx75iwxT5CiPEOqD0Zfxx16GMZ4oFgLKV/Tk8aoDhENbnd5nTjVPBdx 1EqexMv2QS9vGDNdbmxK6N2fkK2+eDu9N61T3xms7kNnsEdAeU3BKGRu9EIUjwASKOsX 9O0PuOTVaAie804Z2Srw+pIJI2GEEuu5gIzPrB+69Jhzt2+ekykAKuBpGUY1N1XB2IwJ MKKA==
X-Gm-Message-State: AOAM531nRgS0kpBTauoBJx/hc1uQwkeDZmZkZp/rktDH2O1r6orRPF6s IXhuO26OcN+khQkbYEkIJRPRTgxlJVdUXDASNyhHQg==
X-Google-Smtp-Source: ABdhPJze/qGzMGgtSLld2w6LIQEH5iPzkH4cwXCSw3Tw+jwEbJh+2o3GjIjmeBZl7VMeCgUpTTYnQnH016q/HNwhd+g=
X-Received: by 2002:a2e:9744:: with SMTP id f4mr777018ljj.199.1625165687387; Thu, 01 Jul 2021 11:54:47 -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>
In-Reply-To: <CABNhwV3BXk=+fuxVSg_9j+u+5Ffr+NQGE9P75NCPpTaUr5LqYQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 1 Jul 2021 20:54:36 +0200
Message-ID: <CAOj+MMFxM_yvrPDEyQ+dpO7ZxoiQKa0DE4ZQf763Cuidj76QXg@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Enke Chen <enchen@paloaltonetworks.com>, Jenny Yuan <jyuan@paloaltonetworks.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/related; boundary="0000000000007fcd6b05c6145f82"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HnYpAcwtbr38F2wg0htYXC-7YAc>
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:55:01 -0000

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*
>
>