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

[[e-mail]]

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