Re: [auth48] AUTH48: RFC-to-be 9494 <draft-ietf-idr-long-lived-gr-06> for your review

[John Scudder <[e-mail]>]

Hi Megan,

Thanks for your reply. See in line.

> On Oct 31, 2023, at 5:02 PM, Megan Ferguson <[e-mail]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John and Bruno,
> 
> Thank you for your reply.
> 
> Please note that we did not receive Bruno’s initial message (on October 3),

Weird. Not to bust your chops, but is there anything to be concerned about concerning the non-delivery? I do see Bruno’s email in the archive, https://mailarchive.ietf.org/arch/msg/auth48archive/oFCF_oNuj7OSDEeRK8qFbp7XBlM/

But in any case, this question is tangential to moving the publication forward.

> but have updated the points that were highlighted in John’s reply to that message.  Please let us know if any further updates are necessary.
> 
> We had the following comments/questions that we will await resolution of prior to moving forward in the publication process.
> 
> 1) With regard to the following from Bruno’s email:
> 
>>> §3.1 says  "This [LLGR] capability MUST be advertised in conjunction with the Graceful Restart capability ;"
>>> §4.1 says "The Graceful Restart capability MUST be advertised in conjunction with the LLGR capability." (i.e., the other way around)
>>> 
>>> I'm not sure whether "conjunction" is "bijective" or not.
>>> - If not, both sentences would not mean the same thing.
>>> - if yes, I don't think that this is exactly what we mean.
>>> 
>>> What we mean, in very simple terms, is: If the LLGR capability is sent, then the GR capability MUST be sent.
>>> But we don't want to imply the other way around. (Since this RFC does not update RFC4724, I don't think that someone could understand it wrongly)
>>> 
>>> I'll leave anyone else to suggest text. (or just drop the comment as being paranoiac)
>> 
>> I think you’re right.
> 
> Please let us know how you would like to update using the Old/New format.

Section 3.1:

OLD:
   The "Long-Lived Graceful Restart Capability", or "LLGR Capability",
   (value: 71) is a BGP capability [RFC5492] that can be used by a BGP
   speaker to indicate its ability to preserve its state according to
   the procedures of this document.  This capability MUST be advertised
   in conjunction with the Graceful Restart capability [RFC4724]; see
   Section 4.1.

NEW:
   The "Long-Lived Graceful Restart Capability", or "LLGR Capability",
   (value: 71) is a BGP capability [RFC5492] that can be used by a BGP
   speaker to indicate its ability to preserve its state according to
   the procedures of this document.  If the LLGR capability is advertised,
   the Graceful Restart capability [RFC4724] MUST also be advertised; see
   Section 4.1.

Section 4.1:

OLD:
   The Graceful Restart capability MUST be advertised in conjunction
   with the LLGR Capability.  If it is not so advertised, the LLGR
   Capability MUST be disregarded.  The purpose for mandating that both
   be used in conjunction is to enable the reuse of certain base
   mechanisms that are common to both "flavors": notably origination,
   collection, and processing of EoR, as well as the finite-state-
   machine modifications and connection-reset logic introduced by GR.

NEW:
   If the LLGR Capability is advertised, the Graceful Restart capability MUST 
   also be advertised.  If it is not so advertised, the LLGR
   Capability MUST be disregarded.  The purpose for mandating this
   is to enable the reuse of certain base
   mechanisms that are common to both "flavors": notably origination,
   collection, and processing of EoR, as well as the finite-state-
   machine modifications and connection-reset logic introduced by GR.

> 3) With regard to the following:
> 
>>> 
>>> §4.2
>>> 
>>> " Similar to [RFC4724], once the session is re-established, if the F
>>> bit for a specific address family is not set in the newly received
>>> LLGR Capability, or if a specific address family is not included in
>>> the newly received LLGR Capability or if the LLGR and accompanying GR
>>> Capability are not received in the re-established session at all,
>>> then the Helper MUST immediately remove all the stale routes from the
>>> peer that it is retaining for that address family."
>>> 
>>> My reading is that the above sentence could be read as changing RFC4724 by saying that if a specific address family is not included in the newly received LLGR Capability then the Helper MUST immediately remove all the [GR] stale routes, including during the GR "Restart Time".
>>> 
>>> I would suggest the minimal change below
>>> OLD: once the session is re-established
>>> NEW: once the session is re-established after the duration of the "Restart Time"
>> 
>> Agreed on the principle. For example, the new GR cap might advertise a given AFI/SAFI with nonzero restart time, and the LLGR cap might not advertise that AFi/SAFI at all… which elsewhere we say is an implicit LLGR time. So yeah, in that case it should only be policed once the LLGR phase is initiated.
>> 
>> A little concerned that the proposed wording might not be clear, but let’s see it in context and we can re-review.
> 
> 
> [rfced] Might we use something like:
> 
> “…after the expiration of the “Restart Time”…”
> or
> “…once the duration of the “Restart Time” has passed…”
> 
> Note that this change has not been made in the current version.  We will await guidance prior to proceeding on this issue.

I notice that a few paragraphs up, we define the term “LLGR Period” to mean exactly what’s needed. So, my suggestion is,

OLD:
   Similar to [RFC4724], once the session is re-established, the Helper
   MUST immediately remove all the stale routes from the peer that it is
   retaining for that address family if any of the following occur:

NEW:
   Similar to [RFC4724], once the LLGR Period begins, the Helper
   MUST immediately remove all the stale routes from the peer that it is
   retaining for that address family if any of the following occur:

> 4) Please review our updates to remove quotes and make various terms from our previous query consistent.  Please let us know if any further updates are necessary or any objections to the changes made.

Will do, and will reply separately.

> 5) We see that the document title uses “Long-Lived BGP Graceful Restart”.  In the document itself, we see many instances of "Long-Lived Graceful Restart Capability” (the IANA-registered value) that do not include “BGP".   Note also that we see instances of “BGP LLGR”.  Should these be made uniform with regard to including BGP and its placement?  If so, please let us know how to update (and we can notify IANA if necessary).

I think we can get rid of “BGP” in almost all these instances. I see “BGP LLGR” in Section 6 (only), all of those can be just “LLGR”. I do think we should keep “BGP” in the title, but it could be made more uniform by changing "Support for Long-Lived BGP Graceful Restart” to "Support for BGP Long-Lived  Graceful Restart” or "Long-Lived Graceful Restart for BGP”. I propose the latter, the “support for” seems superfluous. 

Thanks,

—John

> Please review the files carefully as we do not make changes after publication.
> 
> The files have been posted here (please refresh):
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9494.txt__;!!NEt6yMaO-gk!HUDcNAJNTyTmb3Y_7MwUeOgKz66QVCHMSonwe-VbK_M42hH2tMJOGF3vPh4yliDj24OftL9oD6g_ehU$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9494.pdf__;!!NEt6yMaO-gk!HUDcNAJNTyTmb3Y_7MwUeOgKz66QVCHMSonwe-VbK_M42hH2tMJOGF3vPh4yliDj24OftL9oF6EUmXk$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9494.html__;!!NEt6yMaO-gk!HUDcNAJNTyTmb3Y_7MwUeOgKz66QVCHMSonwe-VbK_M42hH2tMJOGF3vPh4yliDj24OftL9oZNWeED4$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9494.xml__;!!NEt6yMaO-gk!HUDcNAJNTyTmb3Y_7MwUeOgKz66QVCHMSonwe-VbK_M42hH2tMJOGF3vPh4yliDj24OftL9ocpCVdec$
> 
> The relevant diff files have been posted here (please refresh):
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9494-diff.html__;!!NEt6yMaO-gk!HUDcNAJNTyTmb3Y_7MwUeOgKz66QVCHMSonwe-VbK_M42hH2tMJOGF3vPh4yliDj24OftL9oZPb_iCk$  (comprehensive diff)
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9494-auth48diff.html__;!!NEt6yMaO-gk!HUDcNAJNTyTmb3Y_7MwUeOgKz66QVCHMSonwe-VbK_M42hH2tMJOGF3vPh4yliDj24OftL9oXvV9AWs$  (AUTH48 changes only)
> 
> Please contact us with any further updates/questions/comments you may have.
> 
> We will await approvals from each of the parties listed on the AUTH48 status page prior to moving forward to publication.
> 
> The AUTH48 status page for this document is available here:
> 
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9494__;!!NEt6yMaO-gk!HUDcNAJNTyTmb3Y_7MwUeOgKz66QVCHMSonwe-VbK_M42hH2tMJOGF3vPh4yliDj24OftL9oI8ZBfNc$
> 
> Thank you.
> 
> RFC Editor/mf
> 
> 
> 
>> On Oct 24, 2023, at 6:21 PM, John Scudder <jgs=[e-mail]> wrote:
>> 
>> Hi All,
>> 
>>> On Oct 2, 2023, at 3:39 PM, [e-mail] wrote:
>>> 
>>> You may submit your changes in one of two ways:
>>> 
>>> An update to the provided XML file
>> 
>> I’ve attached the updated XML file. I’ve made some changes directly, and have also interspersed comments flagged with [jgs].
>> 
>> —John
>> 
>> <rfc9494-jgs-edits.xml>
> 
> 
> 
> 
>