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. > >
- [Idr] draft-uttaro-idr-bgp-persistence Robert Raszuk
- Re: [Idr] draft-uttaro-idr-bgp-persistence bruno.decraene
- Re: [Idr] draft-uttaro-idr-bgp-persistence Jakob Heitz (jheitz)
- Re: [Idr] draft-uttaro-idr-bgp-persistence Robert Raszuk
- Re: [Idr] draft-uttaro-idr-bgp-persistence bruno.decraene