[RTG-DIR] Rtgdir last call review of draft-ietf-idr-long-lived-gr-02

[Mike McBride via Datatracker <[e-mail]>]

Reviewer: Mike McBride
Review result: Has Nits

Nice document which is fairly easy to understand. Here are some items, for your
consideration, which should make it even better:

Introduction:

1. "The second is the increasing use of BGP as a transport for data less
closely associated with packet forwarding than was originally the case." new:
"The second is the increasing use of BGP as a transport for data *which is*
less closely associated...

2. "In the GR case, the tradeoff between advertising new route status (at the
cost of routing churn) and not advertising it (at the cost of suboptimal or
incorrect route selection) is resolved in favor of not advertising, and in the
LLGR case, it is resolved in favor of advertising new state, and using stale
information only as a last resort."

new: GR should be defined before its first use particularly since it's prior to
the definitions. Would simply suggest "In the Graceful Restart (GR) case," new:
Very long sentence. Would recommend adding a period after the third use of
"advertising". And then start new sentence with "In the LLGR case,...".

Page 8:

1. "After the session goes down and before the session is re-established, the
stale routes for an AFI/SAFI MUST be retained."

new: a comma after "down".

Page 9:

1. "So, for example, if the "Restart Time" is zero..."

new: remove "So" and start with "For example,"

2. "We observe that during the first interval, while the procedures of GR are
in effect, route preference would not be affected, while during the second
interval, while LLGR procedures are in effect, routes would be treated as
least-preferred as specified elsewhere in this document."

new: Very long and a tad confusing. Would recommend a period after "affected".
And then the new second sentence would start as "During the second interval..."

Page 11:

1. "In this document, when we refer to treating a route as least-preferred,
this means the route MUST be treated as less preferred than any other route
that is not so treated."

new: I would recommend: "When referring to the treatment of a route as
least-preferred, the route MUST be treated..."

Page 15:

1. "Depreferencing EBGP routes is considered safe, no different from the common
practice of applying a routing policy to an EBGP session. However, the same is
not always true of IBGP.

Consistent route selection is a fundamental tenet of IBGP correctness and safe
operation in hop-by-hop routed networks.  When routers within an AS apply
different criteria in selecting routes, they can arrive at inconsistent route
selections, potentially with the consequence of forming forwarding loops unless
some form of tunneled forwarding is used to prevent "core" routers from making
a (potentially inconsistent) forwarding decision based on the IP header."

new:"Depreferencing EBGP routes is considered safe, no different from the
common practice of applying a routing policy to an EBGP session. However, the
same is not always true of IBGP. Consistent route selection is a fundamental
tenet of IBGP correctness and safe operation in hop-by-hop routed networks. 
When routers, within an AS, apply different criteria in selecting routes, they
can arrive at inconsistent route selections. This may form forwarding loops
unless some form of tunneled forwarding is used to prevent "core" routers from
making a (potentially inconsistent) forwarding decision based on the IP header."