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

[John Scudder <[e-mail]>]

Hi Mike,

Thanks for your review. I either adopted all your suggestions verbatim, or made related edits.

Regards,

—John

> On Nov 29, 2022, at 10:23 PM, Mike McBride via Datatracker <[e-mail]> wrote:
> 
> 
> 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."
> 
>