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

[John Scudder <[e-mail]>]

One thing I noticed while starting to review the AUTH48 diff is that we use “new capability”, “new BGP capability”, “new BGP well-known communities”, “new BGP communities”, and “new registry”. In the time that’s passed since I wrote or edited those words, I’ve become allergic to this kind of use of “new” — it doesn’t age well. I think in all the cases I’ve just mentioned, we can elide “new” without loss of clarity. I can propose this in OLD/NEW form if wanted, but hopefully, it should be clear enough without that?

(Alas, s/new//g doesn’t quite work, there are some legit uses of “new” in the spec.)

Thanks,

—John

> 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), 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.
> 
> 
> 2) With regard to this issue:
>>> ---
>>> §4.1
>>> 
>>> OLD: We observe that, if support for conventional Graceful Restart is not
>>> desired for the session, the conventional GR phase can be skipped by
>>> omitting all AFIs/SAFIs from the GR capability, advertising a Restart
>>> Time of zero, or both.
>>> 
>>> NEW:
>>> We observe that, if support for conventional Graceful Restart is not
>>> desired for the session, the conventional GR phase can be skipped by
>>> omitting all AFIs/SAFIs from the GR capability, _or_ advertising a Restart
>>> Time of zero, or both.
>>> 
>>> (adding "or" before " advertising a Restart Time of zero")
>>> Totally up to you. An explicit "or" would typically be required in French to distinguish from an implicit "and". May be "or" is implicit in English.
>> 
>> Doesn’t seem necessary but I leave it to the pros to decide.
> 
> 
> 
> [rfced] Because the list ends in “or both”, it is clear that the items in the list are alternatives.  We have left this as was.
> 
> 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.
> 
> 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.
> 
> 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).
> 
> 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>
> 
> 
> 
> 
>