Re: [Idr] draft-uttaro-idr-bgp-persistence
<bruno.decraene@orange.com> Tue, 30 July 2019 14:17 UTC
Return-Path: <bruno.decraene@orange.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 BDCDF120241 for <idr@ietfa.amsl.com>; Tue, 30 Jul 2019 07:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 cqV7j1Shcf4x for <idr@ietfa.amsl.com>; Tue, 30 Jul 2019 07:17:35 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB05B1201EE for <idr@ietf.org>; Tue, 30 Jul 2019 07:17:34 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 45ydtN6fxhz2xhV; Tue, 30 Jul 2019 16:17:32 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 45ydtN5h8Fz1xpF; Tue, 30 Jul 2019 16:17:32 +0200 (CEST)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Tue, 30 Jul 2019 16:17:32 +0200
From: bruno.decraene@orange.com
To: Robert Raszuk <robert@raszuk.net>
CC: "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence
Thread-Index: AQHVReTHGnZo9jQ5GUeP/wLFLSWQc6bjM7YQ
Date: Tue, 30 Jul 2019 14:17:31 +0000
Message-ID: <25379_1564496252_5D40517C_25379_366_1_53C29892C857584299CBF5D05346208A48BC0422@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <CAOj+MME=scL9h7d9Jbh_3vYch6dTruTpseGLXx=peLwexEwH0Q@mail.gmail.com>
In-Reply-To: <CAOj+MME=scL9h7d9Jbh_3vYch6dTruTpseGLXx=peLwexEwH0Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48BC0422OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CY7iJmy18PA5-zI0zqAtWApf3iw>
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 14:17:38 -0000
Hi Robert, From: Idr [mailto: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