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

From: Robert Raszuk <[email-masked]>
Date: Mon, 29 Jul 2019 10:07:38 +0200

Hi,

Assume LLGR has been negotiated and routes have been exchanged with LLGR
community. The retention timer is looong.

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

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.

---

From: <[email-masked]>
Date: Tue, 30 Jul 2019 14:17:31 +0000

Hi Robert,

From: Idr [mailto:[email-masked]] 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

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.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 30 Jul 2019 20:38:05 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, July 30, 2019 7:18 AM
To: Robert Raszuk <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence

Hi Robert,

Hi,

King regards,

--Bruno

Kind regards,
R.

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Jul 2019 23:16:20 +0200

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) <[email-masked]>
wrote:

> *From:* Idr <[email-masked]> *On Behalf Of *
> [email-masked]
> *Sent:* Tuesday, July 30, 2019 7:18 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>
> *Subject:* Re: [Idr] draft-uttaro-idr-bgp-persistence
>
>
>
> Hi Robert,
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *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,
>
>
>
> ‘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)
>
>
>
>
>
> persistent routes. GR procedures which rely on using GR time for it do
> not apply.
>
>
>
>    procedures specified in [RFC4724 <https://tools.ietf.org/html/rfc4724>] and [RFC8538 <https://tools.ietf.org/html/rfc8538>] continue to apply
>
> 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).
>
>
>

---

From: <[email-masked]>
Date: Wed, 31 Jul 2019 07:38:10 +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:[email-masked]]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, July 30, 2019 7:18 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence

Hi Robert,

Hi,

King regards,

--Bruno

Kind regards,
R.

Thank you.