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

[<[e-mail]>]

Hi Robert,

From: Idr [mailto:[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.