draft-ietf-grow-ops-reqs-for-bgp-error-handling-00.txt   draft-ietf-grow-ops-reqs-for-bgp-error-handling-01.txt 
Internet Engineering Task Force R. Shakir Internet Engineering Task Force R. Shakir
Internet-Draft C&W Internet-Draft C&W
Intended status: Informational April 15, 2011 Intended status: Informational June 28, 2011
Expires: October 17, 2011 Expires: December 30, 2011
Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 Operational Requirements for Enhanced Error Handling Behaviour in BGP-4
draft-ietf-grow-ops-reqs-for-bgp-error-handling-00 draft-ietf-grow-ops-reqs-for-bgp-error-handling-01
Abstract Abstract
BGP-4 is utilised as a key intra- and inter-Autonomous System routing 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 protocol in modern IP networks. The failure modes as defined by the
original protocol standards are based on a number of assumptions original protocol standards are based on a number of assumptions
around the impact of session failure. Numerous incidents both in the around the impact of session failure. Numerous incidents both in the
global Internet routing table and within Service Provider networks global Internet routing table and within Service Provider networks
have been caused by strict handling of a single invalid UPDATE have been caused by strict handling of a single invalid UPDATE
message causing large-scale failures in one or more Autonomous message causing large-scale failures in one or more Autonomous
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 17, 2011. This Internet-Draft will expire on December 30, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of BGP-4 in Service Provider Networks . . . . . . . . 3 1.1. Role of BGP-4 in Service Provider Networks . . . . . . . . 3
1.2. Overview of Operator Requirements for BGP-4 Error 1.2. Overview of Operator Requirements for BGP-4 Error
Handling . . . . . . . . . . . . . . . . . . . . . . . . . 4 Handling . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Avoiding use of NOTIFICATION . . . . . . . . . . . . . . . . . 6 2. Errors within BGP-4 UPDATE Messages . . . . . . . . . . . . . 6
3. Recovering RIB Consistency . . . . . . . . . . . . . . . . . . 8 3. Avoiding use of NOTIFICATION . . . . . . . . . . . . . . . . . 8
4. Reducing the Impact of Session Reset . . . . . . . . . . . . . 10 4. Recovering RIB Consistency . . . . . . . . . . . . . . . . . . 10
5. Operational Toolset for Monitoring BGP . . . . . . . . . . . . 12 5. Reducing the Impact of Session Reset . . . . . . . . . . . . . 12
6. Operational Complexities Introduced by Altering RFC4271 . . . 14 6. Operational Toolset for Monitoring BGP . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Operational Complexities Introduced by Altering RFC4271 . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Informational References . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. Informational References . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Where BGP-4 [RFC4271] is deployed in the Internet and Service Where BGP-4 [RFC4271] is deployed in the Internet and Service
Provider networks, numerous incidents have been recorded due to the Provider networks, numerous incidents have been recorded due to the
manner in which [RFC4271] specifies errors in routing information manner in which [RFC4271] specifies errors in routing information
should be handled. Whilst the behaviour defined in the existing should be handled. Whilst the behaviour defined in the existing
standards retains utility, the deployments of the protocol have standards retains utility, the deployments of the protocol have
changed within modern networks, resulting in significantly different changed within modern networks, resulting in significantly different
demands for protocol robustness. Whilst a number of Internet Drafts demands for protocol robustness. Whilst a number of Internet Drafts
have been written to begin to enhance the behaviour of BGP-4 in terms have been written to begin to enhance the behaviour of BGP-4 in terms
of the handling of erroneous messages, this draft intends to define a of the handling of erroneous messages, this memo intends to define a
set of requirements for ongoing work. These requirements are set of requirements for ongoing work. These requirements are
considered from the perspective of a Network Operator, and hence this considered from the perspective of a Network Operator, and hence this
draft does not intend to define the protocol mechanisms by which such draft does not intend to define the protocol mechanisms by which such
error handling behaviour is to be implemented. error handling behaviour is to be implemented.
1.1. Role of BGP-4 in Service Provider Networks 1.1. Role of BGP-4 in Service Provider Networks
BGP was designed as an inter-Autonomous System (AS) routing protocol BGP was designed as an inter-Autonomous System (AS) routing protocol
and hence many of the error handling mechanisms within the protocol and hence many of the error handling mechanisms within the protocol
specification are designed to be conducive to this role. In general, specification are designed to be conducive to this role. In general,
skipping to change at page 6, line 5 skipping to change at page 6, line 5
is extremely limited - where further modifications to this is extremely limited - where further modifications to this
behaviour are to be made, complexity is likely to be added. Thus, behaviour are to be made, complexity is likely to be added. Thus,
to ensure that BGP-4 is manageable, there are requirements for to ensure that BGP-4 is manageable, there are requirements for
mechanisms by which the protocol can be examined and monitored. mechanisms by which the protocol can be examined and monitored.
This document describes each of these requirements in further depth, This document describes each of these requirements in further depth,
along with an overview of means by which they are expected to be along with an overview of means by which they are expected to be
achieved. In addition, the mechanism by which the enhancements achieved. In addition, the mechanism by which the enhancements
meeting these requirements are to interact is discussed. meeting these requirements are to interact is discussed.
2. Avoiding use of NOTIFICATION 2. Errors within BGP-4 UPDATE Messages
Both through analysis of incidents occurring with the Internet DFZ,
and multi-service environments utilising BGP-4 to signal service or
routing information, a number of different classes of errors within
BGP-4 UPDATE messages have been observed. In order to consider the
applicability of enhanced error handling mechanisms, it is possible
to divide these errors into a number of sub-classes, particularly
focusing around the location of the error within the UPDATE message.
Where an UPDATE message is considered invalid by a BGP speaker due to
an error within a path attribute that is not the NLRI (where the
definition of NLRI includes reachability information encoded in the
MP_REACH_NLRI and MP_UNREACH_NLRI attributes as specified in
[RFC4760]) it is a requirement of any enhanced error handling
mechanism to handle the error in a manner focused on the NLRI
contained within the message. Since in this case, the message
received from the remote peer is syntactically valid, it is
considered that such an UPDATE is indicative of erroneous data within
a path attribute - as such, it cannot be assumed that the BGP speaker
from whom the message was received is directly responsible for the
erroneous information - and hence affecting all NLRI received via a
specific session is disproportionate.
Two further error cases exist within UPDATE messages, both of which
are related to the mechanisms that are applicable to messages
received where some difficulty exists in parsing the entire BGP
message. The two cases concern those cases where a valid NLRI
attribute can be extracted, and those where such an attribute is not
able to be parsed. In these cases, errors in the packing of
attributes within a BGP message may have occurred. Such errors are
likely indicative of an error specifically caused by the remote BGP
speaker. It is, however, desirable to an operator that such errors
are handled without affecting all NLRI across a BGP session. As
such, there is a key requirement to maximise the number of cases in
which it is possible to extract NLRI from a BGP UPDATE message. To
this end, it is required that where possible the MP_REACH and
MP_UNREACH attributes are utilised for encoding all NLRI (including
IPv4 Unicast), and that this attribute is included as the first
attribute of a BGP UPDATE message (as originally recommended in
[I-D.chen-ebgp-error-handling]). Such a change to the order of
inclusion of this attribute maximises the number of cases in which
NLRI can be extracted from an UPDATE. Where this is possible, it is
again required that the error handling mechanisms utilised should be
directly applied to the NLRI included in the UPDATE.
For all cases whereby NLRI can be obtained from an UPDATE message, it
is expected that the requirements outlined in Section 3 should be
considered by any enhancement to the BGP-4 protocol.
In the case that it is not possible to completely parse the NLRI
attribute from the UPDATE message received from a peer, it is
extremely likely that this is indicative of a serious error with
either the process of attribute packing, or buffer usage on the
remote BGP speaker. In this case, clearly, it is not possible to
apply any error handling mechanism that is limited to a specific set
of NLRI, since an implementation has no knowledge of the NLRI
included within the UPDATE message. In addition, such errors are
considered to be relatively fundamental to the operation of a BGP
implementation, and hence may indicate a case whereby significant
system errors have occurred. The current BGP-4 standard results in a
BGP speaker restarting a session with the remote BGP speaker.
However where such an error does occur, it is required that a
graceful mechanism is utilised to provide a lower impact to network
operation. The requirements for enhancements of this nature to BGP-4
are outlined in Section 5, with the requirements outlined therein
focused on providing a means by which system integrity can be
restored whilst allowing for continued network operation.
3. Avoiding use of NOTIFICATION
The error handling behaviour defined in RFC4271 is problematic due to The error handling behaviour defined in RFC4271 is problematic due to
the limited options that are available to an implementation. When an the limited options that are available to an implementation. When an
erroneous BGP message is received, at the current time, the erroneous BGP message is received, at the current time, the
implementation must either ignore the error, or send a NOTIFICATION implementation must either ignore the error, or send a NOTIFICATION
message, after which it is mandatory to terminate the BGP session. message, after which it is mandatory to terminate the BGP session.
It is apparent that this requirement is at odds with that of protocol It is apparent that this requirement is at odds with that of protocol
robustness. robustness.
There is significant complexity to this requirement. The mechanism There is significant complexity to this requirement. The mechanism
skipping to change at page 8, line 5 skipping to change at page 10, line 5
It is considered that, if extended to cover iBGP, the mechanisms It is considered that, if extended to cover iBGP, the mechanisms
described in [I-D.chen-ebgp-error-handling] and described in [I-D.chen-ebgp-error-handling] and
[I-D.ietf-idr-optional-transitive] provide a means to avoid the [I-D.ietf-idr-optional-transitive] provide a means to avoid the
transmission of a NOTIFICATION to a remote BGP speaker based on a transmission of a NOTIFICATION to a remote BGP speaker based on a
single erroneous message, where at all possible, and hence meet this single erroneous message, where at all possible, and hence meet this
requirement. The failure cases whereby NLRI cannot be extracted from requirement. The failure cases whereby NLRI cannot be extracted from
the UPDATE message represent a case whereby the receiving system the UPDATE message represent a case whereby the receiving system
cannot handle the error gracefully based on this mechanism. cannot handle the error gracefully based on this mechanism.
3. Recovering RIB Consistency 4. Recovering RIB Consistency
The recommendations described in Section 2 may result in the RIB for The recommendations described in Section 3 may result in the RIB for
a topology within an AS being inconsistent across the AS' internal a topology within an AS being inconsistent across the AS' internal
routers. Alternatively, where such mechanisms are deployed at an AS routers. Alternatively, where such mechanisms are deployed at an AS
boundary, interconnects between two ASes may be inconsistent with boundary, interconnects between two ASes may be inconsistent with
each other. There are therefore risks of traffic blackholing, due to each other. There are therefore risks of traffic blackholing, due to
missing routing information, or forwarding loops. Whilst this is missing routing information, or forwarding loops. Whilst this is
deemed an acceptable compromise in the short term, clearly, it is deemed an acceptable compromise in the short term, clearly, it is
suboptimal. Therefore, a requirement exists to provide mechanisms by suboptimal. Therefore, a requirement exists to provide mechanisms by
which a BGP speaker is able to recover the consistency of the Adj- which a BGP speaker is able to recover the consistency of the Adj-
RIB-In for a particular neighbour. RIB-In for a particular neighbour.
It is envisaged that during such routing inconsistencies, the local It is envisaged that during such routing inconsistencies, the local
BGP speaker is aware that some routing information was not able to be BGP speaker is aware that some routing information was not able to be
processed - due to the fact that an UPDATE message was not parsed processed - due to the fact that an UPDATE message was not parsed
correctly. If the 'treat-as-withdraw' mechanism described within correctly. If the 'treat-as-withdraw' mechanism described within
Section 2 is utilised, it is also possible for the local BGP speaker Section 3 is utilised, it is also possible for the local BGP speaker
to have determined the set of NLRI for which an erroneous UPDATE to have determined the set of NLRI for which an erroneous UPDATE
message was received. In this scenario, by utilising targeted message was received. In this scenario, by utilising targeted
mechanisms to re-request the specific NLRI that was unreachable, this mechanisms to re-request the specific NLRI that was unreachable, this
routing information can be re-transmitted from the remote BGP routing information can be re-transmitted from the remote BGP
speaker. Such a request requires extension to the existing BGP-4 speaker. Such a request requires extension to the existing BGP-4
protocol, in terms of specific UPDATE generation filters with a protocol, in terms of specific UPDATE generation filters with a
transient lifetime. It is envisaged that the work within transient lifetime. It is envisaged that the work within
[I-D.zeng-one-time-prefix-orf] provides a mechanism allowing targeted [I-D.zeng-one-time-prefix-orf] provides a mechanism allowing targeted
elements of the Adj-RIB-In for a BGP neighbour to be recovered. elements of the Adj-RIB-In for a BGP neighbour to be recovered.
skipping to change at page 10, line 5 skipping to change at page 12, line 5
mechanisms are utilised. It is not advisable that a transitive mechanisms are utilised. It is not advisable that a transitive
filter and advertisement mechanism is triggered by all error handling filter and advertisement mechanism is triggered by all error handling
events due to the load this is likely to place on the neighbour events due to the load this is likely to place on the neighbour
receiving such a request. Where this BGP speaker is a relatively receiving such a request. Where this BGP speaker is a relatively
centralised device - a route reflector (as described by [RFC4456]) centralised device - a route reflector (as described by [RFC4456])
for example - the act of generation of UPDATE messages with such for example - the act of generation of UPDATE messages with such
frequency is likely to cause disproportionate load. It is therefore frequency is likely to cause disproportionate load. It is therefore
an operational requirement of such mechanisms that means of request an operational requirement of such mechanisms that means of request
dampening be required by any such extension. dampening be required by any such extension.
4. Reducing the Impact of Session Reset 5. Reducing the Impact of Session Reset
Even where protocol enhancements allow errors in the BGP-4 protocol Even where protocol enhancements allow errors in the BGP-4 protocol
to cease to trigger NOTIFICATION messages, and hence reset a BGP to cease to trigger NOTIFICATION messages, and hence reset a BGP
session, it is clear that some error conditions may not be exited. session, it is clear that some error conditions may not be exited.
In particular, errors due to existing state, or memory structures, In particular, errors due to existing state, or memory structures,
associated with a specific BGP session will not be handled. It is associated with a specific BGP session will not be handled. It is
therefore important to consider how these error conditions are therefore important to consider how these error conditions are
currently handled by the protocol. It should be noted that the currently handled by the protocol. It should be noted that the
following discussion and analysis considers only those NOTIFICATION following discussion and analysis considers only those NOTIFICATION
messages generated in response to errors in UPDATE messages (as messages generated in response to errors in UPDATE messages (as
defined by Section 6.3 in [RFC4271]). defined by Section 6.3 in [RFC4271]).
The existing NOTIFICATION behaviour triggers a reset of all elements The existing NOTIFICATION behaviour triggers a reset of all elements
of the BGP-4 session, as described in Section 6 of [RFC4271]. It is of the BGP-4 session, as described in Section 6 of [RFC4271]. It is
expected that session teardown requires an implementation to re- expected that session teardown requires an implementation to re-
initialise all structures and state required for session maintenance. initialise all structures and state required for session maintenance.
Clearly, there is some utility to this requirement, as error Clearly, there is some utility to this requirement, as error
conditions in BGP are, in general, exited from. However, this conditions in BGP are, in general, exited from. However, this
definition is responsible for the forwarding outages within networks definition is responsible for the forwarding outages within networks
utilising BGP for route propagation when each error is experienced. utilising BGP for route propagation when each error is experienced.
The requirement described in Section 2 is intended to reduce the The requirement described in Section 3 is intended to reduce the
cases whereby a NOTIFICATION is required, however, any mechanism cases whereby a NOTIFICATION is required, however, any mechanism
implemented as a response to this requirement by definition cannot implemented as a response to this requirement by definition cannot
provide a session reset to the extent of that achieved by the current provide a session reset to the extent of that achieved by the current
behaviour. behaviour.
In order to address this, there is a requirement for a means by which In order to address this, there is a requirement for a means by which
a BGP speaker can signal that an unhandled error condition in an a BGP speaker can signal that an unhandled error condition in an
UPDATE message occurred - requiring a session reset - yet also UPDATE message occurred - requiring a session reset - yet also
continue to utilise the paths advertised by the neighbour that are continue to utilise the paths advertised by the neighbour that are
currently in use within the RIB. In this case, the Adj-RIB-In currently in use within the RIB. In this case, the Adj-RIB-In
skipping to change at page 12, line 5 skipping to change at page 14, line 5
forwarding and control plane is common in many devices, as well as forwarding and control plane is common in many devices, as well as
process separation for software-based devices - corruption of a process separation for software-based devices - corruption of a
specific protocol daemon does not necessarily imply forwarding is specific protocol daemon does not necessarily imply forwarding is
affected. Indeed, where forwarding behaviour of a device is affected. Indeed, where forwarding behaviour of a device is
affected, it is envisaged that a failure detection mechanism (be it affected, it is envisaged that a failure detection mechanism (be it
Bidirectional Forwarding Detection, or indeed BGP KEEPALIVE packets) Bidirectional Forwarding Detection, or indeed BGP KEEPALIVE packets)
will detect such a failure in almost all cases, with the symptomatic will detect such a failure in almost all cases, with the symptomatic
behaviour of such a failure being an invalid UPDATE message in very behaviour of such a failure being an invalid UPDATE message in very
few other cases. few other cases.
5. Operational Toolset for Monitoring BGP 6. Operational Toolset for Monitoring BGP
A significant complexity that is introduced through the requirements A significant complexity that is introduced through the requirements
defined in this document is that of monitoring BGP session status for defined in this document is that of monitoring BGP session status for
an operator. Although the existing error handling behaviour causes a an operator. Although the existing error handling behaviour causes a
disproportionate failure, session failure is extremely visible to disproportionate failure, session failure is extremely visible to
most operational personnel within a Network Operator due to both most operational personnel within a Network Operator due to both
existing definitions of SNMP trap mechanisms for BGP, along with the existing definitions of SNMP trap mechanisms for BGP, along with the
forwarding impact typically caused by such a failure. By introducing forwarding impact typically caused by such a failure. By introducing
mechanisms by which errors of this nature are not as visible, this is mechanisms by which errors of this nature are not as visible, this is
no longer the case. There is a requirement that where subsets of the no longer the case. There is a requirement that where subsets of the
skipping to change at page 12, line 45 skipping to change at page 14, line 45
including the information as to the set of NLRI that were considered including the information as to the set of NLRI that were considered
invalid. Whilst with some mechanisms this is achieved by default invalid. Whilst with some mechanisms this is achieved by default
(for example, One-Time Prefix ORF [I-D.zeng-one-time-prefix-orf] (for example, One-Time Prefix ORF [I-D.zeng-one-time-prefix-orf]
(Outbound Route Filtering) will transmit the set of prefixes that are (Outbound Route Filtering) will transmit the set of prefixes that are
required), the operator requirement is to know which prefixes may required), the operator requirement is to know which prefixes may
have been unreachable in all cases. It is envisaged that an have been unreachable in all cases. It is envisaged that an
extension to meet this requirement will allow for such information to extension to meet this requirement will allow for such information to
be transmitted between peers, and hence logged. Such a mechanism may be transmitted between peers, and hence logged. Such a mechanism may
provide further utility as a either a diagnostic, or logging toolset. provide further utility as a either a diagnostic, or logging toolset.
It should be noted that numerous work items within the IETF exist at As such, it is possible to divide the messages that are required in
the time of writing that begin to solve this requirement. Within the order to provide further visibility into BGP for an operator. Such a
IDR working group both [I-D.raszuk-bgp-diagnostic-message] and division can be made both due to the required means of message
[I-D.ietf-idr-advisory] provide mechanisms by which such information transmission, alongside the criticality of each request.
can be propagated in-band to an existing BGP session. Transmitting
such diagnostic information in-band is considered the optimal means
by which to propagate details of errors present in UPDATE messages,
due to the fact that no additional protocols (and hence security and
trust concerns) must be configured between two Autonomous Systems
(where the errors occur at an AS boundary), and the load on each BGP
speaker is increased only due to an additional capability, rather
than an additional code base, and protocol. Clearly, any mechanism
implemented in-band to a BGP session is required to be relatively
lightweight, since the information provided over the session is an
enhancement to the operational visibility of the protocol, and should
not disrupt core protocol operations. Other, out-of-band, mechanisms
- such as that proposed in [I-D.ietf-grow-bmp] are likely to provide
mechanisms by which further insight into BGP operation can be
achieved. The fact that such a protocol is implemented independently
of the BGP protocol results in further flexibility to provide
detailed protocol data, without introducing further complexity to the
BGP protocol itself.
6. Operational Complexities Introduced by Altering RFC4271 o Messages required to replace NOTIFICATION - In cases where the
error handling mechanisms defined by [RFC4271] currently result in
a NOTIFICATION message being generated, a number of the
requirements detailed within this document result this message
being suppressed. Despite this change, the error condition's
occurrence is still of interest to an operator, since some form of
invalid data has been received on a session in order to provide
both monitoring and troubleshooting capabilities. It therefore
considered that an implementation must generate a message both
locally, and transmitted to the remote peer, based on the such a
condition. Where such a message is transmitted to the remote
peer, it is considered that the BGP session via which the
erroneous UPDATE message was received as transport to the remote
peer. The information transmitted in such a message should be
minimised to allow identification of the paths which were
considered erroneous (i.e. restricting the information to that
which is directly relevant to a network operator in the case of an
error condition occurring). Any delay to convergence on the
session in question is considered to be acceptable, given the
suboptimal nature of the reception of invalid routing information
via a BGP session. Further concerns regarding such a mechanism
relate to the load generated on the BGP speaker in question,
however, it must be considered that in the case of an erroneous
UPDATE being received, and the 'treat-as-withdraw' mechanism being
utilised, where the erroneous path is removed from the Loc-RIB,
there is likely to be a requirement to generate UPDATE messages
withdrawing the prefix from all further BGP speakers to which the
prefix is advertised. The load generated by the generation of
such UPDATEs is likely to be much greater than that of
transmitting error information via a logging message type back to
the speaker from which it was received. It is envisaged that
light-weight BGP message-based signalling mechanisms such as
[I-D.ietf-idr-advisory] provide a suitable means to satisfy this
requirement.
o Additional Diagnostic Capabilities for BGP - In a number of cases,
there is an operational requirement to further debug erroneous BGP
UPDATE messages, along with the particulars of the state of a BGP
speaker. For instance, where an invalid BGP UPDATE message is
transmitted between two BGP speakers, the exact format of the
UPDATE message is of interest to an operator, as this information
provides a clear indication of an message considered to be
erroneous by the BGP speaker to which it was transmitted. In this
case, it is considered of great utility that the entire UPDATE
message is transmitted back to the advertising speaker, in order
to allow for further debugging to occur. Whilst such information
is particularly useful to an operator, it clearly provides
information that is not key to protocol operation - for this
reason, it is expected that some of the concerns regarding the
additional complexity, and load that a BGP speaker is subjected to
is not acceptable. For this reason, it is required that where
mechanisms are developed to support this requirement, messages of
this nature can be supported both within an existing BGP session,
and via a dedicated separate session, be it BGP carrying messages
such as DIAGNOSTIC [I-D.raszuk-bgp-diagnostic-message] or ADVISORY
[I-D.ietf-idr-advisory] or a dedicated monitoring protocol akin to
BMP described in [I-D.ietf-grow-bmp].
Whilst the operational requirement for such monitoring tools to allow
for visibility into BGP is clearly agreed upon, the means by which
such messages are transmitted between two BGP speakers is likely to
be dependent upon both the positions of the speakers in question (for
instances, the requirements for such a protocol may differ where a
session is between two ASBRs under separate administration). The
introduction of additional message types to the BGP protocol clearly
introduces further complexity - and leaves room for further
implementation and standardisation errors that may compromise the
robustness of the BGP protocol. In addition, the queuing and
scheduling of these BGP messages must be interleaved with the
transmission of the key protocol messages - such as KEEPALIVE and
UPDATE packets. It is therefore a concern that should a large number
of messages specifically for operational visibility be transmitted,
this will delay the transmission of UPDATE packets, and hence
adversely affect the end-to-end convergence time for NLRI carried
within BGP. The operational requirement for why messages are
advantageous to be in-band to a protocol should also be considered.
In particular, it should be noted that where such information is to
be transmitted between administrative boundaries a BGP session
represents an existing channel exists between the two ASes. This
channel is considered to be secure insofar as the routing
information, and requests sent via the session are considered to come
from a trusted source. Since error information relates to both a
particular attachment, and is key to ensuring that such a session is
operating as expected, it is considered of great operational benefit
that this information is transmitted over this channel. In addition,
the overall system scalability is improved by such in-band
transmission. It is expected that erroneous information resulting in
the 'treat-as-withdraw' mechanism being utilised is relatively
infrequently transmitted between two peers (when compared to the
frequency of UPDATE messages transmission). The impact of including
an additional BGP message type for such operational visibility is
relatively small from a resource utilisation perspective - additional
processing overhead is only experienced when such a message is
received. Where a separate session is maintained, particular network
elements within a service provider topology may require hundreds, or
thousands, of additional sessions for the transmission of this
information. Such an resource consumption overhead is likely to be
unacceptable to some network operators.
For the reasons explained above, it is expected that mechanisms
specified to meet the requirements for event visibility consider the
relative impacts of additional monitoring sessions, or message
inclusion in band to BGP in order not to compromise the security,
scalability and robustness of the BGP-4 protocol.
7. Operational Complexities Introduced by Altering RFC4271
The existing NOTIFICATION and subsequent teardown of a BGP session The existing NOTIFICATION and subsequent teardown of a BGP session
upon encountering an error has the advantage that a consistent upon encountering an error has the advantage that a consistent
approach to error handling is required of all implementations of the approach to error handling is required of all implementations of the
BGP-4 protocol. This is of operational advantage, as it provides a BGP-4 protocol. This is of operational advantage, as it provides a
clear expectation of the behaviour of the protocol. The requirements clear expectation of the behaviour of the protocol. The requirements
defined herein add further complexity to the error-handling within defined herein add further complexity to the error-handling within
BGP, and hence are liable to compromise the existing deterministic BGP, and hence are liable to compromise the existing deterministic
protocol behaviour. It is therefore deemed that there is a further protocol behaviour. It is therefore deemed that there is a further
requirement to provide a clear method by which an erroneous UPDATE requirement to provide a clear method by which an erroneous UPDATE
skipping to change at page 14, line 32 skipping to change at page 18, line 32
BGP implementations), where some of the mechanisms referenced are BGP implementations), where some of the mechanisms referenced are
unsupported. This adds further barriers to a standard definition of unsupported. This adds further barriers to a standard definition of
the BGP-4 error handling behaviour. the BGP-4 error handling behaviour.
In general, the approach considered ideal upon encountering an In general, the approach considered ideal upon encountering an
erroneous UPDATE message can be divided into two cases - those where erroneous UPDATE message can be divided into two cases - those where
the NLRI can be determined from the message, and those where it the NLRI can be determined from the message, and those where it
cannot be. The latter case is the simpler of the two. In this case, cannot be. The latter case is the simpler of the two. In this case,
there is a requirement for the implementation to reset the BGP there is a requirement for the implementation to reset the BGP
session, utilising the reduced-impact approach, described in session, utilising the reduced-impact approach, described in
Section 4. In the case where the remote BGP speaker is in a Section 5. In the case where the remote BGP speaker is in a
transient error condition related to specific peer data structures, transient error condition related to specific peer data structures,
or state, a single instance of this behaviour is likely to exit the or state, a single instance of this behaviour is likely to exit the
error condition. In the case of implementation errors, it is error condition. In the case of implementation errors, it is
possible that the BGP session in question may enter a continuous loop possible that the BGP session in question may enter a continuous loop
of being reset, with a partial RIB being held by one or more of the of being reset, with a partial RIB being held by one or more of the
BGP speakers due to an non-deterministic order of UPDATE propagation. BGP speakers due to an non-deterministic order of UPDATE propagation.
It is therefore a requirement that within this reduced-impact It is therefore a requirement that within this reduced-impact
procedure any subsequent UPDATE messages that would result in further procedure any subsequent UPDATE messages that would result in further
session resets are ignored. Whilst this results in a condition where session resets are ignored. Whilst this results in a condition where
an undetermined amount of the RIB is inconsistent, partial an undetermined amount of the RIB is inconsistent, partial
reachability is maintained. In this case, the operational toolsets reachability is maintained. In this case, the operational toolsets
discussed in Section 5 is likely to provide mechanisms by which this discussed in Section 6 is likely to provide mechanisms by which this
condition can be brought to the attention of the relevant operators. condition can be brought to the attention of the relevant operators.
This requirement to accept a partial RIB, which results in potential This requirement to accept a partial RIB, which results in potential
invalid traffic forwarding is a direct result of the deployments of invalid traffic forwarding is a direct result of the deployments of
BGP-4, as described in Section 1.1. BGP-4, as described in Section 1.1.
The case where NLRI can be determined from an erroneous UPDATE The case where NLRI can be determined from an erroneous UPDATE
provides further complexities. In this case, a BGP speaker is aware provides further complexities. In this case, a BGP speaker is aware
of the sub-set of the RIB which have been identified as being of the sub-set of the RIB which have been identified as being
contained within invalid UPDATE messages. This allows a local BGP contained within invalid UPDATE messages. This allows a local BGP
speaker to re-request single prefixes, utilising a mechanism such as speaker to re-request single prefixes, utilising a mechanism such as
skipping to change at page 15, line 29 skipping to change at page 19, line 29
number of specific requests transmitted to be defined. number of specific requests transmitted to be defined.
2. Where a specific refresh mechanism is not available, a peer 2. Where a specific refresh mechanism is not available, a peer
should re-request the entire RIB. Again, there is a requirement should re-request the entire RIB. Again, there is a requirement
to limit the number of complete RIB requests that should be sent to limit the number of complete RIB requests that should be sent
via an implementation, in order to provide a bound both on the via an implementation, in order to provide a bound both on the
expected level of load a device may experience, and on the time expected level of load a device may experience, and on the time
for which the RIB may be inconsistent. for which the RIB may be inconsistent.
3. Finally, a session reset should be performed, as per the reduced- 3. Finally, a session reset should be performed, as per the reduced-
impact NOTIFICATION requirement defined in Section 4. At this impact NOTIFICATION requirement defined in Section 5. At this
point, a similar challenge to that discussed above exists, should point, a similar challenge to that discussed above exists, should
the error condition persist. In this case, as defined above, the error condition persist. In this case, as defined above,
there is a requirement to ignore those UPDATE messages that there is a requirement to ignore those UPDATE messages that
continue to be erroneous. continue to be erroneous.
It is envisaged that where limits are required, these will be defined It is envisaged that where limits are required, these will be defined
on a per memo-basis, or within a further revision of the requirements on a per memo-basis, or within a further revision of the requirements
described herein. described herein.
Whilst the approach described above provides a standard means by Whilst the approach described above provides a standard means by
skipping to change at page 17, line 5 skipping to change at page 21, line 5
the number of error handling events sourced towards a particular the number of error handling events sourced towards a particular
neighbour. It is expected that such rate limiting, or event neighbour. It is expected that such rate limiting, or event
suppression is achieved on a per-session basis, where state suppression is achieved on a per-session basis, where state
information is already held, rather than on a per-prefix basis as it information is already held, rather than on a per-prefix basis as it
is envisaged that such behaviour presents significant scaling is envisaged that such behaviour presents significant scaling
problems, and introduces further state requirements for an problems, and introduces further state requirements for an
implementation of the protocol. It is recommended that where a flag implementation of the protocol. It is recommended that where a flag
indicative of erroneous behaviour is implemented, the state of such a indicative of erroneous behaviour is implemented, the state of such a
value is maintained independently of session establishment. value is maintained independently of session establishment.
7. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 9. Security Considerations
The requirements outlined in this document provide mechanisms by The requirements outlined in this document provide mechanisms by
which erroneous BGP messages may be responded to with limited impact which erroneous BGP messages may be responded to with limited impact
to forwarding operation. This is of benefit to the security of a BGP to forwarding operation. This is of benefit to the security of a BGP
speaker in general. Where UPDATE messages may have been propagated speaker in general. Where UPDATE messages may have been propagated
by a single malicious Autonomous System or router within a network by a single malicious Autonomous System or router within a network
(or the Internet default free zone - DFZ), which are then propagated (or the Internet default free zone - DFZ), which are then propagated
to all devices within the same routing domain, all other NLRI to all devices within the same routing domain, all other NLRI
available over the same session become unreachable. This mechanism available over the same session become unreachable. This mechanism
may provide means by which an Autonomous System can be isolated from may provide means by which an Autonomous System can be isolated from
required routing domains (such as the Internet), should the relevant required routing domains (such as the Internet), should the relevant
UPDATE messages be propagated via specific paths. By reducing the UPDATE messages be propagated via specific paths. By reducing the
impact of such failures, it is envisaged that this possibility may be impact of such failures, it is envisaged that this possibility may be
constrained to a specific set of NLRI, or a specific topology. constrained to a specific set of NLRI, or a specific topology.
Some mechanisms meeting the requirements specified in this document, Some mechanisms meeting the requirements specified in this document,
particularly those within Section 5 may provide further security particularly those within Section 6 may provide further security
concerns, however, it is envisaged that these are addressed in per- concerns, however, it is envisaged that these are addressed in per-
enhancement memos. enhancement memos.
9. Acknowledgements 10. Acknowledgements
The author would like to thank Rob Evans, David Freedman, Tom The author would like to thank Shane Amante, Bruno Decraene, Rob
Hodgson, Sven Huster, Jonathan Newton, Neil McRae, Thomas Mangin, Tom Evans, David Freedman, Tom Hodgson, Sven Huster, Jonathan Newton,
Scholl and Ilya Varlashkin for their review and valuable feedback. Neil McRae, Thomas Mangin, Tom Scholl and Ilya Varlashkin for their
review and valuable feedback.
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.chen-ebgp-error-handling] [I-D.chen-ebgp-error-handling]
Chen, E., Mohapatra, P., and K. Patel, "Revised Error Chen, E., Mohapatra, P., and K. Patel, "Revised Error
Handling for BGP Updates from External Neighbors", Handling for BGP Updates from External Neighbors",
draft-chen-ebgp-error-handling-00 (work in progress), draft-chen-ebgp-error-handling-00 (work in progress),
September 2010. September 2010.
[I-D.ietf-grow-bmp] [I-D.ietf-grow-bmp]
Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring
Protocol", draft-ietf-grow-bmp-05 (work in progress), Protocol", draft-ietf-grow-bmp-05 (work in progress),
skipping to change at page 21, line 16 skipping to change at page 25, line 16
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006. (IBGP)", RFC 4456, April 2006.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007. January 2007.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009. with BGP-4", RFC 5492, February 2009.
10.2. Informational References 11.2. Informational References
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
June 2010. June 2010.
Author's Address Author's Address
Rob Shakir Rob Shakir
Cable&Wireless Worldwide Cable&Wireless Worldwide
London
UK
Email: rob.shakir@cw.com Email: rjs@cw.net
URI: http://www.cw.com/ URI: http://www.cw.com/
 End of changes. 28 change blocks. 
61 lines changed or deleted 225 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/