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

[Megan Ferguson <[e-mail]>]

Greetings,

Just a friendly weekly reminder that this document awaits your attention.  Please see the document-specific questions and AUTH48 announcement in this thread and let us know if we can be of assistance as you begin the AUTH48 review process.

Please note that the AUTH48 status page of this document is viewable at:

http://www.rfc-editor.org/auth48/rfc9494

AUTH48 FAQs are available at https://www.rfc-editor.org/faq/#auth48.

We look forward to hearing from you at your earliest convenience.

Thank you.

RFC Editor/mf


> On Oct 2, 2023, at 1:39 PM, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 1) <!--[rfced] Past RFCs list J. Scudder instead of J. G. Scudder.  May
>     we update this document to match?-->
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
>     the title) for use on https://www.rfc-editor.org/search. -->
> 
> 
> 3) <!--[rfced] We see some citations to RFC 4724 that mention its
>     relationship to RFC 8538, but a number that do not.  Perhaps a
>     generic statement early in the document might be helpful to the
>     reader?  Otherwise, may the reader assume that the update is only
>     mentioned when the text in this document is referring to text in
>     both documents (and citations to only RFC 4724 are not impacting
>     RFC 8538 at all)?  If so, please review the use and let us know
>     if any updates are necessary.
> 
> Instances where the update is currently mentioned:
> 
> Original:
> BGP Graceful Restart [RFC4724], updated by [RFC8538],...
> 
> ... the procedures specified in [RFC4724] and [RFC8538] continue to
> apply...
> 
> -->
> 
> 
> 4) <!--[rfced] We had a few questions about the following text.  Please
>     review our points of concern and the suggested text and let
>     us know how to proceed.
> 
> a) May we avoid "When used, its use"? Please see our rephrasing below
> and let us know any objections.
> 
> b) To what does "its" refer?  We believe it is the extension.  Please
> see our rephrase below and let us know any objections.
> 
> c) It seems contradictory to use "only" but then give an alternative.
> We have updated this text.  Please let us know if this change is
> acceptable.
> 
> d) May we reorder "immediately" and "after the traditional Graceful
> Restart interval has elapsed" to improve flow?
> 
> e) What is the "it" that is invoked?  The extension?  This is not
> addressed in our suggested text below.  Please let us know how we may
> update.
> 
> Original:
> When used, its use may be combined with that of traditional Graceful
> Restart, in which case it is invoked only after the traditional
> Graceful Restart interval has elapsed, or it may be invoked
> immediately.
> 
> Perhaps:
> The use of this extension may be combined with that of traditional
> Graceful Restart; in such a case, it is invoked either immediately or
> after the traditional Graceful Restart interval has elapsed.
> 
> -->
> 
> 
> 5) <!--[rfced] We had the following questions/comments about Section 2
>     (Definitions):
> 
> a) We have broken this section into subsections (and changed its title
> to "Terminology").  Definitions and Abbreviations were broken into
> separate subsections in order to make the lists parallel in
> punctuation/structure and for the ease of the reader.  We pulled the
> Requirements Language section in as it seemed related.  Please let us
> know any objections.
> 
> b) We see several of the abbreviations expanded in a manner that may
> cloud the 1:1 relationship between initialism and expansion.
> 
> Original:
> CE:  A Customer Edge router.  [RFC4364]
> EoR:  Marker for End-of-RIB, defined in [RFC4724] Section 2.
> PE:  A Provider Edge router.  [RFC4364]
> VRF:  VPN Routing and Forwarding table.  [RFC4364]
> 
> We have updated these definitions to use only the expansion (i.e., CE
> is expanded to Customer Edge, not Customer Edge router).  Please
> review the instances of the above abbreviations throughout the body of
> the document and let us know if/how to update.
> 
> For instance, may we update "until EoR" to appear as "until the EoR
> marker" in the following text.
> 
> Original:
> The timer is neither stopped nor updated until EoR is received for the
> relevant AFI/SAFI from the peer.
> 
> c) We removed the listing of "depreferenced" and made the entry only
> the base form of "depreference".  It is not necessary to list all
> participial derivatives of the term (and we see "depreferencing" was
> not included in the original).
> 
> -->
> 
> 
> 6) <!--[rfced] In the figure in Section 3.1, we note that the text
>     leading into the figure and the figure itself use different
>     forms:
> 
> a) Should the sentence leading into the figure use expansions to match
> the figure?
> 
> b) Should "Flags" be updated to match the figure (i.e., "Flags for
> Address Family")?
> 
> Perhaps:
> The capability value consists of zero or more tuples <Address Family
> Identifier, Subsequent Address Family Identifier, Flags for Address
> Family, Long-lived Stale Time> as follows:
> 
> -->
> 
> 
> 7) <!--[rfced] We had two questions regarding the F bit and Forwarding
>     State:
> 
> a) In the first sentence below, it sounds like F bit = Forwarding
> State.  In the second sentence below, it sounds like F bit and
> "Forwarding State" bit are two different things. Perhaps a rephrase of
> the second sentence would help clarify this for the reader?
> 
> Original:
> This bit is called the "F bit" since it was historically used to
> indicate the preservation of Forwarding State.
> 
> Original:
> The setting of the F bit (and the "Forwarding State" bit of the
> accompanying GR capability)...
> 
> b) We see forwarding state, Forwarding State, and "Forwarding State".
> Please let us know if/how we may make these uniform.
> 
> -->
> 
> 
> 8) <!--[rfced] For the ease of the reader, may we update to include a
>     citation to what the authors mean by "base BGP specification"?
>     We note this update is a bit redundant: if a rephrase is desired,
>     please let us know how you would like to appear.
> 
> 
> Original:
> ...only those of the base BGP specification (although EoR would still
> be used as detailed in [RFC4724]).
> 
> Perhaps:   
> ...only those of the base BGP specification ([RFC4724]) (although EoR
> would still be used as detailed in [RFC4724]).
> -->
> 
> 
> 9) <!--[rfced] Please review our edit to the following text (changing
>     "but" to "and") and let us know if this changes the intended
>     meaning.
> 
> Original:
>   *  If any of the routes from the peer have been marked with the
>      NO_LLGR community, either as sent by the peer, or as the result of
>      a configured policy, they MUST NOT be retained, but MUST be
>      removed as per the normal operation of [RFC4271].
> 
> Current:
>   *  If any of the routes from the peer have been marked with the
>      NO_LLGR community, either as sent by the peer or as the result of
>      a configured policy, they MUST NOT be retained and MUST be
>      removed as per the normal operation of [RFC4271].
> -->
> 
> 
> 10) <!--[rfced] Might a reorganization of this sentence for the ease of
>     the reader be agreeable?
> 
> Original:
>   Similarly 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.
> 
> Perhaps:
> 
>   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:
> 
> *  the F bit for a specific address family is not set in the newly
>      received LLGR Capability, or
> 
> *  a specific address family is not included in the newly received
>      LLGR Capability, or 
> 
> *  the LLGR and accompanying GR Capability are not received in the
>      re-established session at all.
> -->
> 
> 
> 11) <!--[rfced] We had two questions about the following text:
> 
> a) Note that we would like to break up this sentence for the ease of
> the reader.  Please review to ensure we have maintained your intended
> meaning.
> 
> Original:
> This leads to a problem: in this specification, we take pains to
> ensure that "stale" routing information will not leak beyond the
> perimeter of routers that support these procedures so that it can be
> depreferenced as expected, and we provide a workaround (Section 4.6)
> for the case where one or more IBGP routers are not upgraded.
> 
> Perhaps:
> This leads to a problem: in this specification, we take pains to
> ensure that "stale" routing information will not leak beyond the
> perimeter of routers that support these procedures.  This is so that
> "stale" routing information can be depreferenced as expected.  We
> provide a workaround (see Section 4.6) for the case in which one or
> more IBGP routers are not upgraded.
> 
> b) In the above sentence, the reader may be led to believe that the
> text following "problem:" is going to directly describe the problem
> itself, not what the specification is doing to avoid it.  Perhaps
> adding some text in or rewording to describe the problem and how the
> document addresses it might help?
> 
> 
> 
> 
> -->
> 
> 
> 12) <!--[rfced] We had a few sentences where we were unsure about whether
>     a clause was restrictive or not:
> 
> a) In the following sentence, is the clause about having no non-stale
> alternate paths available restrictive or not?  That is, do these
> normal rules apply to only the stale more-specific routes that have no
> non-stale alternate paths available (other stale more-specific routes
> exist that have non-stale alternate paths available)?  If so, Perhaps
> A might be best.  If you are simply providing more information about
> all stale more-specific routes (they all have no non-stale alternate
> paths available), Perhaps B would be the way to go.
> 
> Original:
> However, according to the normal rules of IP forwarding a stale
> more-specific route, that has no non-stale alternate paths available,
> will still be used instead of a non-stale less-specific route.
> 
> Perhaps A:
> However, according to the normal rules of IP forwarding, a stale
> more-specific route that has no non-stale alternate paths available
> will still be used instead of a non-stale less-specific route.
> 
> Perhaps B:
> However, according to the normal rules of IP forwarding, a stale
> more-specific route, which has no non-stale alternate paths available,
> will still be used instead of a non-stale less-specific route.
> 
> b) In the following, is the group you are talking about only the
> dedicated route reflectors that do not participate in the forwarding
> plane (as opposed to those that do participate)?  Or is the fact that
> dedicated route reflectors don't participate in the forwarding plane
> something true about all route reflectors?
> 
> Original:
> Likewise, for control-plane-only entities such as dedicated route
> reflectors, that do not participate in the forwarding plane, it makes
> sense to always set the F bit.
> 
> Perhaps:
> Likewise, for control-plane-only entities such as dedicated route
> reflectors that do not participate in the forwarding plane, it makes
> sense to always set the F bit.
> -->
> 
> 
> 13) <!--[rfced] Might the suggested text below clarify who is doing the
>     exploiting?
> 
> 
> Original:
> In order to exploit the vulnerability described above, there is a
> requirement to engineer a specific LLGR state between two PE devices,
> whilst engineering label reallocation to occur in a manner that
> results in the two topologies overlapping.  Therefore, to avoid the
> potential for a VPN breach, before enabling BGP LLGR for a VPN address
> family, the operator should endeavor to ensure that the lower bound on
> when a label might be reused is greater than the upper bound on LLST.
> 
> 
> Perhaps:
> In order to exploit the vulnerability described above, an attacker
> needs to engineer a specific LLGR state between two PE devices and
> also cause the label reallocation to occur such that the two
> topologies overlap.  To avoid the potential for a VPN breach, the
> operator should ensure that the lower bound for label reuse is greater
> than the upper bound on the LLST before enabling BGP LLGR for a VPN
> address family.
> 
> -->
> 
> 
> 14) <!--[rfced] Please review our updates to this text to ensure we have
>     retained your intended meaning.  Note that the original was
>     missing a closing parenthesis, so we want to make sure we
>     interpreted correctly.
> 
> Original:
>   *  The label allocation policy on the PE (possibly depending upon the
>      size of the pool of the VPN labels (which can be restricted by
>      hardware considerations or other MPLS usages), the label
>      allocation scheme (for example per route or per VRF/CE), the re-
>      allocation policy (for example least recently used label).
> 
> 
> Perhaps:
>   *  The label allocation policy on the PE, which possibly depends upon
>      the size of the pool of the VPN labels (which can be restricted by
>      hardware considerations or other MPLS usages), the label
>      allocation scheme (for example, per route or per VRF/CE), and the
>      reallocation policy (for example, least recently used label).
> -->
> 
> 
> 15) <!--[rfced] In the following sentence, is text missing after "stale"
>     (stale is an adjective)?  Note that this sentence appears more than
>     once.
> 
> Original:
> ASBR1 transitions RR's routes to long-lived stale by attaching the
> LLGR_STALE community and depreferencing them.
> 
> Perhaps:
> ASBR1 transitions RR's routes to long-lived stale routes by attaching
> the LLGR_STALE community and depreferencing them.
> 
> -->
> 
> 
> 16) <!--[rfced] FYI - In pointers to other sections, we have removed the
>     section titles for consistency within the document and with other
>     RFCs.  Note that this also eliminates an overabundance of links
>     in the html.  Please let us know any objections.-->
> 
> 
> 17) <!-- [rfced] Throughout the text, the following terminology appears to
>     be used inconsistently. Please review these occurrences and let
>     us know if/how they may be made consistent.
> 
> a) Please review the use of both "capability" and "Capability"
> throughout and let us know if/how we may update for consistency.
> 
> b) We note that there were a number of similar terms that may benefit
> from being made consistent (see the list below).
> 
> *Note that we will cap "-lived" throughout to create a 1:1
> relationship with abbreviations/initialisms (and will communicate this
> change to IANA upon the completion of AUTH48 to update the registry
> title at
> https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#long-lived-graceful-restart-flags-for-address-family).
> Please let us know any objections.
> 
> *We further suggest: 1) using quotes only when introducing the term
> (e.g., This is called "LLGR") and 2) using the abbreviated form
> consistently after first expansion (see
> https://www.rfc-editor.org/styleguide/part2/#exp_abbrev).  Please let
> us know any objections.  (Note - this guidance is applicable to all
> terms and abbreviations, not only those in the list below).
> 
> Long-lived BGP Graceful Restart
>        vs. Long-lived Graceful Restart (no BGP)
>        vs. Long-Lived and traditional Graceful Restart
>        vs. "Long-lived Graceful Restart"
>        vs. long-lived GR
> 	vs. BGP LLGR extension (note the placement of BGP compared to above)
> 
> "Long-lived Graceful Restart Capability"
>        vs. Long-lived Graceful Restart Capability (no quotes)
>        vs. LLGR Capability (or capability see point a) above) (again no quotes)
> 	
> "Long-lived Graceful Restart Flags for Address Family"
> 
> long-lived stale routes 
>        vs. Long-Lived Stale routes
>        vs. routes to long-lived stale
> 
> long-lived stale information
> 
> Long-lived Stale Time
>        vs. "Long-lived Stale Time"
> 
> 
> c) As mentioned in b) above, we suggest removing quotes from uses of
> the following terms after they have been introduced:
> 
> "least-preferred"
> "LLGR_STALE"
> "NO_LLGR"
> "Restart Time"
> 
> 
> d) We will remove the hyphens from "least-preferred", "more-specific",
> and "less-specific" in both attributive position and following the
> verb to follow this guidance from CMOS:
> 
> "...compounds with more, most, less, least, and very usually open unless ambiguity threatens"
> 
> Please let us know any objections.
> 
> -->
> 
> 
> 18) <!-- [rfced] We had the following questions/comments regarding
>     abbreviations throughout the document:
> 
> a) FYI - We have added expansions for the following abbreviations on
> first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
> review each expansion in the document carefully to ensure correctness.
> Also, please let us know if any of the following should be added to
> the list of abbreviations in Section 2.
> 
> VPLS - Virtual Private LAN Service 
> FLOWSPEC - Flow Specifier (per RFC 9064)
> NLRI - Network Layer Reachability Information
> IBGP - Internal BGP
> EBGP - External BGP
> BFD - Bidirectional Forwarding Detection
> 
> b) We see uses of "GR Restart Time".  Since the R in GR stands for
> Restart, please review the instances and let us know if/how to
> update.  Note further that not all uses of Restart Time are preceded
> by GR.  Please review and let us know if updates are necessary.
> 
> 
> -->
> 
> 
> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the
>     online Style Guide
>     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>     and let us know if any changes are needed.
> 
> 
> For example, please consider whether the following should be updated:
> black hole / blackholing
> 
> Further, the NIST website
> <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
> indicates that "tradition" is potentially biased and it is also
> ambiguous.
> 
> In this document, we see "conventional GR" introduced, but a number of
> uses of "traditional GR".  May we update such cases to instead use
> "conventional"?
> 
> 
> Below please find a list of each use of tradition* in the document:
> 
> ...traditional routing.
> 
> ...used, its use may be combined with that of traditional Graceful...
> 
> ...Restart; in such a case, it is invoked only after the traditional...
> 
> ...the most obvious difference between Long-Lived and traditional...
> 
> Whereas, in the traditional version, route preference is not...
> 
> ...whereas, in the traditional Graceful Restart case, stale routes are...
> 
> ...conveys traditional reachability information, the use of a long-lived...
> 
> ...traditional hop-by-hop forwarding).
> 
> ...traditional routing.  For such routes, it may make sense to always...
> 
> ...can be constructed for traditional GR, but these are generally...
> 
> 
> -->
> 
> 
> Thank you.
> 
> RFC Editor/kf/mf
> 
> 
> *****IMPORTANT*****
> 
> Updated 2023/10/02
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and 
> approved by you and all coauthors, it will be published as an RFC.  
> If an author is no longer available, there are several remedies 
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties 
> (e.g., Contributors or Working Group) as necessary before providing 
> your approval.
> 
> Planning your review 
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>   Please review and resolve any questions raised by the RFC Editor 
>   that have been included in the XML file as comments marked as 
>   follows:
> 
>   <!-- [rfced] ... -->
> 
>   These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors 
> 
>   Please ensure that you review any changes submitted by your 
>   coauthors.  We assume that if you do not speak up that you 
>   agree to changes submitted by your coauthors.
> 
> *  Content 
> 
>   Please review the full content of the document, as this cannot 
>   change once the RFC is published.  Please pay particular attention to:
>   - IANA considerations updates (if applicable)
>   - contact information
>   - references
> 
> *  Copyright notices and legends
> 
>   Please review the copyright notice and legends as defined in
>   RFC 5378 and the Trust Legal Provisions 
>   (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>   Please review the markup in the XML file to ensure that elements of  
>   content are correctly tagged.  For example, ensure that <sourcecode> 
>   and <artwork> are set correctly.  See details at 
>   <https://authors.ietf.org/rfcxml-vocabulary>.
> 
> *  Formatted output
> 
>   Please review the PDF, HTML, and TXT files to ensure that the 
>   formatted output, as generated from the markup in the XML file, is 
>   reasonable.  Please note that the TXT will have formatting 
>   limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> the parties CCed on this message need to see your changes. The parties 
> include:
> 
>   *  your coauthors
> 
>   *  [e-mail] (the RPC team)
> 
>   *  other document participants, depending on the stream (e.g., 
>      IETF Stream participants are your working group chairs, the 
>      responsible ADs, and the document shepherd).
> 
>   *  [e-mail], which is a new archival mailing list 
>      to preserve AUTH48 conversations; it is not an active discussion 
>      list:
> 
>     *  More info:
>        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> 
>     *  The archive itself:
>        https://mailarchive.ietf.org/arch/browse/auth48archive/
> 
>     *  Note: If only absolutely necessary, you may temporarily opt out 
>        of the archiving of messages (e.g., to discuss a sensitive matter).
>        If needed, please add a note at the top of the message that you 
>        have dropped the address. When the discussion is concluded, 
>        [e-mail] will be re-added to the CC list and 
>        its addition will be noted at the top of the message. 
> 
> You may submit your changes in one of two ways:
> 
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit 
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text, 
> and technical changes.  Information about stream managers can be found in 
> the FAQ.  Editorial changes do not require approval from a stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> Files 
> -----
> 
> The files are available here:
>   https://www.rfc-editor.org/authors/rfc9494.xml
>   https://www.rfc-editor.org/authors/rfc9494.html
>   https://www.rfc-editor.org/authors/rfc9494.pdf
>   https://www.rfc-editor.org/authors/rfc9494.txt
> 
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9494-diff.html
>   https://www.rfc-editor.org/authors/rfc9494-rfcdiff.html (side by side)
> 
> For your convenience, we have also created an alt-diff file that will 
> allow you to more easily view changes where text has been deleted or 
> moved: 
>   http://www.rfc-editor.org/authors/rfc9494-alt-diff.html
> 
> Diff of the XML: 
>   https://www.rfc-editor.org/authors/rfc9494-xmldiff1.html
> 
> The following files are provided to facilitate creation of your own 
> diff files of the XML.  
> 
> Initial XMLv3 created using XMLv2 as input:
>   https://www.rfc-editor.org/authors/rfc9494.original.v2v3.xml 
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only: 
>   https://www.rfc-editor.org/authors/rfc9494.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9494
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9494 (draft-ietf-idr-long-lived-gr-06)
> 
> Title            : Support for Long-lived BGP Graceful Restart
> Author(s)        : J. Uttaro, E. Chen, B. Decraene, J. Scudder
> WG Chair(s)      : Susan Hares, Keyur Patel, Jeffrey Haas
> 
> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> 
>