The document describes revisions to the error handling behavior that
is defined in the base BGP-4 specification (RFC4271). The motivation
for changes to this behaviour is to avoid a single erroneous UPDATE
message (or attribute within such a message) impacting an entire BGP-4
session (and hence all the NLRI that it carries). The document
introduces the "treat-as-withdraw" mechanism, which treats the NLRI
received within an erroneous UPDATE message as though they are
withdrawn by the remote neighbor. Additionally an "attribute discard"
approach is introduced. The document evaluates the existing BGP-4
attributes and defines new error handling behaviours for them. Errors
for which the existing BGP-4 error handling behaviour is to be
retained are also considered.
There is working group consensus amongst both network operators, and
BGP-4 implementors that this mechanism is a useful Standards Track
document to improve the robustness of the BGP-4 protocol, whilst also
considering the correctness of routing information it carries.
Working Group Summary
There has been significant debate relating to the balance of different
functionalities required between working group participants which seek
to maintain established sessions (or retain NLRI during their
failure), and those that consider the correctness of the protocol
paramount. The document's intention was originally to address a point
failure scenario observed within the Internet related to optional
transitive attributes, but based on wider operational experience, the
working group has extended the scope of the document.
The behaviours now included within the document have been subject to
significant review over multiple cycles from both protocol experts,
network operators, and protocol implementors contributing to the
balance between approaches having been reached.
Operational requirements for the changes within the document have been
discussed at length - and reviewed with GROW. Whilst there is some
appetite for additional mechanisms for operators to maintain the
integrity of their networks by compromising correctness of the routing
information in their network - especially during catastrophic failures
- this document does not reflect these additional requirements - which
are subject to separate proposals to the working group.
Significant deployment experience has been gained for the changes
described in the document. The shepherd is aware of four shipping
commercial implementations of BGP-4 (Alcatel-Lucent SR OS, Cisco IOS,
Cisco IOS XR, Juniper JUNOS), and one open source implementation
(Quagga) have implemented the behaviours described in the
document. The feedback from these implementations has helped to
iterate the contents of the document, and reach consensus within the
Status of administrative actions:
Public IPR Call: 11/12 to 11/19/14
Routing Directorate Review status: Joel Halpern (11/18), QA review completed (9/4)
OPS Directorate status: Reviewer: Warren Kumari (11/16) done
Gen-Art Pre-review: Pending, 10/14
IANA: No early review
The document shepherd is Rob Shakir.
The WG Chair responsible: Sue Hares [John Scudder is co-author]
The responsible Area Director is Alvaro Retana.