Hi UK netops, A few UKNOFs ago, I presented on some work that I was kicking off in the IETF relating to changes to the BGP-4 protocol such that the error handling behaviour was aligned with the requirements of modern network deployments. This was in direct relation to a number of live operational issues that had been observed in the Internet DFZ (including issues relating to AS4_PATH, as well as the experiment that the RIPE NCC conducted).
After a number of iterations, this work has resulted in a document describing the requirements for these amendments -- http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling This document has shaped a number of standards that are now being developed in the IETF IDR working group to improve BGP: - An IDR BGP error handling draft is in progress to standardise the "treat-as-withdraw" behaviour, which allows session resets to be avoided based on erroneous BGP UPDATEs where possible. - Further drafts relating to extending ROUTE REFRESH and Graceful Restart have been proposed to allow recovery from inconsistent RIB states, and reduced impact to forwarding when a session reset cannot be avoided respectively. - The work that Tom Scholl, Richard Steenbergen, John Scudder, and David Freedman did on the ADVISORY message has been extended to handle some error handling cases, as well as the original use case. The draft document is now at working group last call GROW (Global Routing Operations WG) in the IETF - this represents the final working group agreement prior to publishing this work. I feel that having a document that describes these requirements is valuable, since it defines the operational problems that future solutions are intended to solve. I would encourage anyone who has an interest in this area to review the document, and let the GROW mailing list (g...@ietf.org) know whether the requirements describe meet their use case, and/or any comments or deviations that should be noted. The last call is intended to end on 25/06. Many thanks in advance for doing so - there are a number of network scenarios that I think will be operationally improved by implementing this work. Kind regards, r.
