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

[Robert Raszuk <[e-mail]>]

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