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

<bruno.decraene@orange.com> Wed, 31 July 2019 07:38 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 8FBAC120071 for <idr@ietfa.amsl.com>; Wed, 31 Jul 2019 00:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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] 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 SDif3p1LEjP7 for <idr@ietfa.amsl.com>; Wed, 31 Jul 2019 00:38:13 -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 49FCE120048 for <idr@ietf.org>; Wed, 31 Jul 2019 00:38:13 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 45z4z72mxrz2xqW; Wed, 31 Jul 2019 09:38:11 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 45z4z71lw2zBrLW; Wed, 31 Jul 2019 09:38:11 +0200 (CEST)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 09:38:10 +0200
From: <bruno.decraene@orange.com>
To: Robert Raszuk <robert@raszuk.net>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>
CC: "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence
Thread-Index: AQHVReTJsa4a0N7XRk6tpHtpYV+EbqbjN0KAgABptAD//+nJAIAAzPSg
Date: Wed, 31 Jul 2019 07:38:10 +0000
Message-ID: <21953_1564558691_5D414563_21953_83_1_53C29892C857584299CBF5D05346208A48BC1695@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
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> <CAOj+MMEtgoeGOwsGQKVOMGk+6H-3ctf2=h0OjzZ6a0ZANKzJpQ@mail.gmail.com>
In-Reply-To: <CAOj+MMEtgoeGOwsGQKVOMGk+6H-3ctf2=h0OjzZ6a0ZANKzJpQ@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_53C29892C857584299CBF5D05346208A48BC1695OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/J1vPecpV2xNjV2AgiYXj26mcoJk>
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: Wed, 31 Jul 2019 07:38:17 -0000

Robert,

If you want to close the BGP session without triggering GR/LLGR, you can send a NOTIFICATION with a hard reset https://tools.ietf.org/html/rfc8538#section-3
If max prefix wants to close the BGP session with GR or LLGR enabled, they may be they should consider sending a hard reset.

Thanks,
--Bruno

From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Tuesday, July 30, 2019 11:16 PM
To: Jakob Heitz (jheitz)
Cc: DECRAENE Bruno TGI/OLN; idr@ietf. org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence


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<mailto: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<mailto:idr-bounces@ietf.org>> On Behalf Of bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Sent: Tuesday, July 30, 2019 7:18 AM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence

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.

_________________________________________________________________________________________________________________________

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.