Hi all, This updated version takes into account the comments received from the IESG.
In addition to various nits, please find below the significant comments and changes. Regards, Bruno --------- Comment 1: How does the operator know when that convergence event is over and it is safe to bring down the BGP session. --------- Requirements "h" & "a" have been rephrased: - the handling of the BGP session (NOTIFICATION/OPEN) is kept in requirement "h" and modified to take into account the comment, - the handling of advertising the nominal path back (when the session is re-established) is moved to the requirement "a". Below the rephrased ยง: "h) The specific procedure SHOULD end when the BGP session is closed following the g-shut and once the BGP session is gracefully open following the g-noshut. In the end, once the planned maintenance is finished the nominal BGP routing MUST be reestablished. The duration of the g-shut procedure, and hence the time before the BGP session is safely closed SHOULD be discussed by the solution document. Examples of possible solutions are the use of a pre-configured timer, of a message to signal the end of the BGP convergence or monitoring the traffic on the g-shut interface..." "a) A mechanism to advertise the maintenance action to all affected routers is REQUIRED. Such mechanism may be either implicit or explicit. Note that affected routers can be located both in the local AS and in neighboring ASes. Note also that the maintenance action can either be the shutdown of a BGP session or the establishment of a BGP session. The mechanism SHOULD minimize packet loss when a path is removed or advertised. In particular, it SHOULD be ensured that the old path is not removed from the routing tables of the affected routers before the new path is known." That way: - the handling of paths (requirement "a") is more clearly separated from the handling of the BGP session (requirement "h") - g-shut (BGP session closed) and g-noshut (BGP session opened) cases are grouped in the same requirements. --------- Comment 2: During the convergence event, there may be micro-loops and packet loss. I suspect that these will not be as bad as the negative impact of bringing down the bgp session without warning, but it would be nice if you could provide some text supporting my suspicion. --------- The section 3.2 already discussed the two main cause of packets loss (lack of path, routing inconsistency). The following sentences are added/modified to enhance the description about micro-loop issues: "Transient routing inconsistencies happen during IBGP convergence because all routers are not updating their RIB at the same time. This can lead to forwarding loops and then packet drops. The duration of these transient micro-loops may depend on the IBGP topology (e.g. number of Route Reflectors between ingress and egress ASBR), implementation differences among router platforms (e.g. speed to update the RIB and FIB, possibly the order in which prefixes are modified), forwarding mode (hop by hop IP forwarding versus tunneling). Transient forwarding loops can be avoided by performing only one IP lookup on BGP routes in each AS and by using tunnels (e.g. MPLS LSP) to send packets between ASBRs. As such, BGP/MPLS VPNs should be immune to such micro forwarding loops." --------- Comment 3: In section 5, you talk about OSPF, ISIS and Static routing in L3VPNs. You should make clear that you are not talking about changing those protocols. You are talking about changing BGP, which may advertise routes learned from those protocols. --------- OLD: "- The shutdown of a customer access router and all of its BGP sessions. In BGP/MPLS VPN as per [VPN], this router is called a CE and the use of others protocols than BGP on the PE-CE access link should also be considered (static routes, RIPv2, OSPF, IS-IS...)." NEW: "Service Providers and vendors implementing a graceful shutdown solution should note that in BGP/MPLS VPN as per [VPN], the PE-CE routing can be performed by other protocols than BGP (e.g. static routes, RIPv2, OSPF, IS-IS...). This is out of scope of this document, but comprehensive graceful shutdown procedures should take this into account. " > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Tuesday, September 07, 2010 10:15 PM > To: [email protected] > Cc: [email protected] > Subject: [GROW] I-D ACTION:draft-ietf-grow-bgp-graceful-shutdown- > requirements-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations Working Group > of the IETF. > > Title : Requirements for the graceful shutdown of BGP sessions > Author(s) : T. Takeda, B. Decraene, P. Francois, c. pelsser, Z. > Ahmad, A. Armengol > Filename : draft-ietf-grow-bgp-graceful-shutdown-requirements- > 04.txt > Pages : 16 > Date : 2010-9-6 > > The Border Gateway Protocol(BGP) is heavily used in Service Provider > networks both for Internet and BGP/MPLS VPN services. For resiliency > purposes, redundant routers and BGP sessions can be deployed to > reduce the consequences of an AS Border Router or BGP session > breakdown on customers' or peers' traffic. However simply taking down > or even bringing up a BGP session for maintenance purposes may still > induce connectivity losses during the BGP convergence. This is not > satisfactory any more for new applications (e.g. voice over IP, on > line gaming, VPN). Therefore, a solution is required for the graceful > shutdown of a (set of) BGP session(s) in order to limit the amount of > traffic loss during a planned shutdown. This document expresses > requirements for such a solution. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-grow-bgp-graceful-shutdown- > requirements-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
