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." -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
