[153766] in North American Network Operators' Group
BGP Error Handling (Fwd: [GROW] WGLC:
daemon@ATHENA.MIT.EDU (Rob Shakir)
Tue Jun 12 06:54:55 2012
From: Rob Shakir <rjs@rob.sh>
Date: Tue, 12 Jun 2012 11:54:42 +0100
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi NANOGers,
Back at NANOG51 in Miami, I gave a presentation relating an IETF draft =
relating to improving the robustness of BGP-4 to meet the requirements =
of current operational deployments, and there was some good discussion =
following this. This document was then presented to the IETF IDR and =
GROW (Global Routing Operations WG), and we have since iterated the =
document to make it significantly clearer, and describe the desired =
operational behaviour.
This work was particularly on the back of the issues that were seen in =
the Internet DFZ relating to malformed AS_PATH, invalid AS4_PATH, and =
the problematic RIPE NCC large optional-transitive advertisement.
The discussion, and the requirements outlined have helped influence a =
number of new standards developments in BGP:
- An IDR BGP error handling draft [0] 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 [1] and Graceful =
Restart [2] 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 [3].
The working group last call represents final agreement prior to =
publishing this work, which is valuable since it provides a framework of =
requirements which future developments are intended to solve.=20
I would encourage anyone who has an interest in this area to review the =
document, and let the GROW mailing list (grow@ietf.org) know whether the =
requirements describe meet their use case, and/or any comments or =
deviations that should be noted.
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.
Begin forwarded message:
> From: Christopher Morrow <christopher.morrow@gmail.com>
> Subject: [GROW] WGLC: =
draft-ietf-grow-ops-reqs-for-bgp-error-handling-04
> Date: 11 June 2012 21:21:49 GMT+01:00
> To: grow-chairs@tools.ietf.org, "grow@ietf.org grow@ietf.org" =
<grow@ietf.org>
>=20
> Hello GROW-WG folk,
> Please take this message as the start of a 2 week, ending 6/25/2012
> (June 25, 2012) WGLC for the subject draft, link to current version:
> =
<http://www.ietf.org/internet-drafts/draft-ietf-grow-ops-reqs-for-bgp-erro=
r-handling-04.txt>
>=20
> Abstract:
> "BGP-4 is utilised as a key intra- and inter-Autonomous System routing
> protocol in modern IP networks. The failure modes as defined by the
> original protocol standards are based on a number of assumptions
> around the impact of session failure. Numerous incidents both in =
the
> global Internet routing table and within Service Provider networks
> have been caused by strict handling of a single invalid UPDATE
> message causing large-scale failures in one or more Autonomous
> Systems.
>=20
> This memo describes the current use of BGP-4 within Service Provider
> networks, and outlines a set of requirements for further work to
> enhance the mechanisms available to a BGP-4 implementation when
> erroneous data is detected. Whilst this document does not provide
> specification of any standard, it is intended as an overview of a =
set
> of enhancements to BGP-4 to improve the protocol's robustness to =
suit
> its current deployment."
>=20
> -Chris
> co-chair
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
