Subject: [RTG-DIR] RtgDir review: draft-ietf-grow-bgp-graceful-shutdown-requirements-04.txt

From: Enke Chen <[email-masked]>
Date: Fri, 01 Oct 2010 14:29:51 -0700

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review. The purpose of the review
is to provide assistance to the Routing ADs. For more information about the
Routing Directorate, please see 
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or
by updating the draft.

Document: draft-ietf-grow-bgp-graceful-shutdown-requirements-04.txt
Reviewer: Enke Chen
Review Date: 27 October 2010
IETF LC End Date: 27 October 2010
Intended Status: Informational

Summary:

In general the goals and the requirements for the "BGP graceful shutdown"
are clearly stated.  I have some comments, though, that I think should be
addressed before publication.

Comments:

The document is about the requirements for "BGP graceful shutdown". It is
an interesting, and relatively new topic, and the requirements are clearly
stated.   However, in the document there are occasional (or scattered)
mentions of "BGP graceful bringup", which seems confusing and unnecessary.

Major Issues:

I suggest that "BGP graceful bringup" related text be either removed 
from the
document for the following reasons:

     - To reduce packet loss during BGP bringup, several techniques have 
been
       developed and are well known, including setting the "overload bit" in
       IS-IS, and using large metrics in OSPF; and also also postponing the
       bringup of external links until the IGPs and IBGPs have converged.

     - When a primary path is added (such as in the case of BGP bringup),
       routing needs to reconverge.  IMO there is not much more that can be
       done or needs to be done than what is already known.

     - It is not clear from the document if there is a new requirement.

Minor Issues:

1) Section 2, Introduction

The draft says:

    Currently, BGP [BGP-4] and MP-BGP [MP-BGP] do not include any
    operation to gracefully withdraw a prefix while traffic toward that
    prefix could still be correctly forwarded. When a BGP session is
    taken down, BGP behaves as if it was a sudden link or router failure
    and withdraws the prefixes learnt over that session, which may
    trigger traffic loss. There is no mechanism to advertise to its BGP
    peers that the prefix will soon be unreachable, while still being
    reachable. When applicable, such mechanism would reduce or prevent
    traffic loss.

This paragraph seems to suggest a particular enhancement ("graceful
prefix withdraw") in the protocol might be needed.  This is a bit
misleading, and may not be the intention.

First, such an enhancement is not really required as there are a number
of parameters (in particular LOCAL-PREF) in BGP that can be used to
influence the degree of preference in route selection, and thus
influence the traffic flow.

Second, this is a requirement document, and is not about a specific
solution to satisfy the requirement.

So I suggest that the text be removed, or expanded to include the
possible re-use of existing protocol machinery.
--------------------------------------------------

-- Enke