Re: [Idr] draft-uttaro-idr-bgp-persistence

Robert Raszuk <robert@raszuk.net> Tue, 30 July 2019 21:16 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 CDBE5120105 for <idr@ietfa.amsl.com>; Tue, 30 Jul 2019 14:16:35 -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, 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 Vvh4TJsZASPk for <idr@ietfa.amsl.com>; Tue, 30 Jul 2019 14:16:32 -0700 (PDT)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 7400D120046 for <idr@ietf.org>; Tue, 30 Jul 2019 14:16:32 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id n11so64409564qtl.5 for <idr@ietf.org>; Tue, 30 Jul 2019 14:16:32 -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=jbgcToB6WaQDVLjJYi0ooEt8WcIrqaaD9zBed0VOg0U=; b=K/zobAfFW7bSsicFfxrk0lMl557sLbvamzExrZQG7O1xHntA0CrYdPZ46RP25PgNqC M12ms1QI+/3aA4Qprf+QvaaySPwD3asyFmwIRrXjW8MigpNeAfeaXhFq32QqPwvlkUOG rBhtdSuLdM4JduXza66vI228yD6au9FRHVmH33rRRgXu33KYT1JZDzPIXMi/2k5d1gtX Pc4tevvzGGKcmZL/q8Qa7cE9MZz8vgBzgk5FrK2sQVj2TN3g5e+mQuDXp26m7M0pVz6p HSEQi6UNRsgdP+BhQKGaAX7bPTk/LQ95iIDNBTKM4Tqu06Q78mmtLbHARHpV4PolcYCL amzA==
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=jbgcToB6WaQDVLjJYi0ooEt8WcIrqaaD9zBed0VOg0U=; b=b4vAIy7ylV0ZjaZZu9yF+u/iYYTBb3m8ce4cTH7LVR+2wmIJlcXt4xKrv+bAKf568s A/k6tHc3dIEESpUQ06WWP5lD2OgOlmkVolpRDBd5F3sPaykSHdlGqqQdyuNWQRmjgVTO vzz60jSimRXu4LxTcBJiNd4k9bnh9USsR9ykGkoDBgggOuteNsm9VqAbBGr5UiPjmigo bG8RdxKiPw5gNL8SdAcHhbGZNUPqjybh9r3DZWW/snUWUPHhLPMxiW8nD8q3Bm3dPe3w L/OAYkVEIcQunMagxxzkGB738T6t1OCvFmmUHBGrJVhOub66kMr+0fIirCuxz8IN2hvr JMVQ==
X-Gm-Message-State: APjAAAWyUj7h29NMyebzeLsZwKnTsfQpP+kFZZUe2Xkc62qVsC1r/M3y MuDjkBwOFEI/EviJFHJbQAU/FBqgKnYWRRPCBZPNkw==
X-Google-Smtp-Source: APXvYqynZnSMpwxHtscwG4NgvxP7sQSlbfK7OKa/hWj1005ef5BcA7DhHdKma1vcL/xFu7/hycHq2CgwQKKzMLDV80Y=
X-Received: by 2002:aed:228d:: with SMTP id p13mr82626489qtc.208.1564521391419; Tue, 30 Jul 2019 14:16:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAOj+MME=scL9h7d9Jbh_3vYch6dTruTpseGLXx=peLwexEwH0Q@mail.gmail.com> <25379_1564496252_5D40517C_25379_366_1_53C29892C857584299CBF5D05346208A48BC0422@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <BYAPR11MB3751FB92FC2F17BCFDC3421DC0DC0@BYAPR11MB3751.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3751FB92FC2F17BCFDC3421DC0DC0@BYAPR11MB3751.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 30 Jul 2019 23:16:20 +0200
Message-ID: <CAOj+MMEtgoeGOwsGQKVOMGk+6H-3ctf2=h0OjzZ6a0ZANKzJpQ@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Cc: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c78bd2058eec8590"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IXSMAnFRyNGps9V8JTcEtD0_pz8>
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence
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: Tue, 30 Jul 2019 21:16:36 -0000

Yes as I noted in my original mail this is clearly a "workaround" to the
problem. But note it only works if operator is aware about the issue.

If BGP session terminates unexpectedly - say when max prefix is reached -
it is quite unclear on the operational consequences of such duet of
features enabled together.

Thx,
R.


On Tue, Jul 30, 2019 at 10:38 PM Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> Robert,
>
>
>
> You can cause your neighbor to delete your routes immediately by bringing
> up a new BGP
>
> session, and send the LLGR capability with the F bit clear and then bring
>
> it right back down again. If you don't want your neighbor to hold your
> routes,
>
> then do not advertise the LLGR capability or set the stale time to 0.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *
> bruno.decraene@orange.com
> *Sent:* Tuesday, July 30, 2019 7:18 AM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* idr@ietf. org <idr@ietf.org>
> *Subject:* Re: [Idr] draft-uttaro-idr-bgp-persistence
>
>
>
> Hi Robert,
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Monday, July 29, 2019 10:08 AM
> *To:* idr@ietf. org
> *Subject:* [Idr] draft-uttaro-idr-bgp-persistence
>
>
>
> Hi,
>
>
>
> Assume LLGR has been negotiated and routes have been exchanged with LLGR
> community. The retention timer is looong.
>
> ‘Long’ or ‘simple’ is a matter of opinion. I’m pretty sure that some,
> possibly you, will consider that an hour is long. While that is in scope
> the Graceful Restart. Compared to GR, persistence minimize the preference
> of the stale routes hence live routes will be preferred. Personally, this
> seems safer than GR (but indeed, this creates additional control plane
> processing)
>
>
>
>
>
> While I am happy to see that suggestions to follow GR procedures have been
> used the draft is pretty silent on one very important aspect - clearing
> persistent routes. GR procedures which rely on using GR time for it do
> not apply.
>
>
>
> Imagine I want to bring such session down and I do want to remove all
> routes including those marked as LLGR. How do I do that ?
>
>
>
> From current draft the only way seems to be to reestablish a session with
> LLGR capability and readvertise subject routes with NO-LLGR community
> hoping it will clear the former routes. But even here we are at the mercy
> of local policy as per section 3.2 & 3.3
>
>  For your case, the BGP session seems to be up or able of been up. Why do you think the use of a hard reset would not work? This seems to be specifically referred to by the specification:
>
> “   In the presence of the "Long-lived Graceful Restart Capability", the
>
>    procedures specified in [RFC4724 <https://tools.ietf.org/html/rfc4724>] and [RFC8538 <https://tools.ietf.org/html/rfc8538>] continue to apply
>
>    unless explicitly revised by this document.”
>
>
>
> For the case where the BGP session is down, clearly a protocol message/behavior is not applicable. I would assume that a local CLI would do this. (E.g. clear ip bgp session). In all cases, this is not specific to BGP persistence and equally applies to GR.
>
>
>
> King regards,
>
> --Bruno
>
>
>
>
>
> In any case that is pretty awkward method.
>
>
>
> Then we just had a little thread regarding max prefix in GROW WG. New
> draft there actually relies on BGP NOTIFICATION MSG with CEASE error code
> to remove all routes making on purpose crossing a max prefix limit a
> drastic event (of course unless warning only is set).
>
>
>
> Bottom line BGP here is used again as configuration tool not as dynamic
> routing protocol. I do not think this type of use of BGP which should be
> endorsed.
>
>
>
> If this proposal moves fwd it should clearly spell how not only to retain
> the LLGR eligible prefixes but also how to cleanly remove them when needed
> - way before they expire.
>
>
>
> Kind regards,
>
> R.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>