draft-ietf-grow-ops-reqs-for-bgp-error-handling-01.txt   draft-ietf-grow-ops-reqs-for-bgp-error-handling-02.txt 
Internet Engineering Task Force R. Shakir Internet Engineering Task Force R. Shakir
Internet-Draft C&W Internet-Draft C&W
Intended status: Informational June 28, 2011 Intended status: Informational October 20, 2011
Expires: December 30, 2011 Expires: April 22, 2012
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-01 draft-ietf-grow-ops-reqs-for-bgp-error-handling-02
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 December 30, 2011. This Internet-Draft will expire on April 22, 2012.
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 23 skipping to change at page 2, line 23
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. Errors within BGP-4 UPDATE Messages . . . . . . . . . . . . . 6 2. Errors within BGP-4 UPDATE Messages . . . . . . . . . . . . . 6
3. Avoiding use of NOTIFICATION . . . . . . . . . . . . . . . . . 8 2.1. Classifying BGP Errors and Expected Error Handling . . . . 7
4. Recovering RIB Consistency . . . . . . . . . . . . . . . . . . 10 2.1.1. Critical BGP Errors . . . . . . . . . . . . . . . . . 7
5. Reducing the Impact of Session Reset . . . . . . . . . . . . . 12 2.1.2. Semantic BGP Errors . . . . . . . . . . . . . . . . . 8
6. Operational Toolset for Monitoring BGP . . . . . . . . . . . . 14 3. Avoiding use of NOTIFICATION . . . . . . . . . . . . . . . . . 9
7. Operational Complexities Introduced by Altering RFC4271 . . . 18 4. Recovering RIB Consistency . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5. Reducing the Impact of Session Reset . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Operational Toolset for Monitoring BGP . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 7. Operational Complexities Introduced by Altering RFC4271 . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Reducing the Network Impact of Session Teardown . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informational References . . . . . . . . . . . . . . . . . 25 11.2. Informational References . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
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
skipping to change at page 6, line 24 skipping to change at page 6, line 24
Where an UPDATE message is considered invalid by a BGP speaker due to 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 an error within a path attribute that is not the NLRI (where the
definition of NLRI includes reachability information encoded in the definition of NLRI includes reachability information encoded in the
MP_REACH_NLRI and MP_UNREACH_NLRI attributes as specified in MP_REACH_NLRI and MP_UNREACH_NLRI attributes as specified in
[RFC4760]) it is a requirement of any enhanced error handling [RFC4760]) it is a requirement of any enhanced error handling
mechanism to handle the error in a manner focused on the NLRI mechanism to handle the error in a manner focused on the NLRI
contained within the message. Since in this case, the message contained within the message. Since in this case, the message
received from the remote peer is syntactically valid, it is received from the remote peer is syntactically valid, it is
considered that such an UPDATE is indicative of erroneous data within considered that such an UPDATE is indicative of erroneous data within
a path attribute - as such, it cannot be assumed that the BGP speaker a path attribute. The impact of the current behaviour defined within
from whom the message was received is directly responsible for the the protocol makes the implication that the BGP speaker from whom the
erroneous information - and hence affecting all NLRI received via a message is received is now an invalid path for all NLRI announced via
specific session is disproportionate. the session - which results in a disproportionate impact to overall
network operation. In particular scenarios (such as networks with
centralised BGP route reflection) such action can result in a loss of
all reachability to a network. In other contexts (such as the
Internet DFZ), it cannot be assumed that the BGP speaker from whom
the UPDATE message is received is directly responsible for the
erroneous information contained within the message.
Two further error cases exist within UPDATE messages, both of which Two further error cases exist within UPDATE messages, both of which
are related to the mechanisms that are applicable to messages are related to the mechanisms that are applicable to messages
received where some difficulty exists in parsing the entire BGP received where some difficulty exists in parsing the entire BGP
message. The two cases concern those cases where a valid NLRI message. The two cases concern those cases where a valid NLRI
attribute can be extracted, and those where such an attribute is not attribute can be extracted, and those where such an attribute is not
able to be parsed. In these cases, errors in the packing of able to be parsed. In these cases, errors in the packing of
attributes within a BGP message may have occurred. Such errors are attributes within a BGP message may have occurred. Such errors are
likely indicative of an error specifically caused by the remote BGP likely indicative of an error specifically caused by the remote BGP
speaker. It is, however, desirable to an operator that such errors speaker. It is, however, desirable to an operator that such errors
skipping to change at page 8, line 5 skipping to change at page 7, line 31
implementation, and hence may indicate a case whereby significant implementation, and hence may indicate a case whereby significant
system errors have occurred. The current BGP-4 standard results in a system errors have occurred. The current BGP-4 standard results in a
BGP speaker restarting a session with the remote BGP speaker. BGP speaker restarting a session with the remote BGP speaker.
However where such an error does occur, it is required that a However where such an error does occur, it is required that a
graceful mechanism is utilised to provide a lower impact to network graceful mechanism is utilised to provide a lower impact to network
operation. The requirements for enhancements of this nature to BGP-4 operation. The requirements for enhancements of this nature to BGP-4
are outlined in Section 5, with the requirements outlined therein are outlined in Section 5, with the requirements outlined therein
focused on providing a means by which system integrity can be focused on providing a means by which system integrity can be
restored whilst allowing for continued network operation. restored whilst allowing for continued network operation.
2.1. Classifying BGP Errors and Expected Error Handling
It is clearly of advantage for BGP-4 implementations to utilise a
consistent set of error handling mechanisms for the different types
of errors that are described in Section 2, and provide consistent
nomenclature to refer to them. It is therefore suggested that errors
that are indicative of larger scale failures of a BGP speaker, and
hence require some error handling at the session level are referred
to as 'critical' errors, whilst those errors that are identified
based on incorrect content of one of more attributes of a message are
referred to as 'semantic' errors.
2.1.1. Critical BGP Errors
As described in this document, it is of advantage to limit the number
of 'critical' errors that occur within the protocol, therefore, based
on analysis of the processing of BGP UPDATE messages, it is required
that 'critical' error handling behaviour is applied to:
o UPDATE Message Length errors - whereby the specified overall
UPDATE message length is inconsistent with sum of the Total Path
Attribute and Withdrawn Routes length. In this case, this is
indicative of message packing failure, whereby the NLRI may not be
correctly extracted.
o Errors Parsing the NLRI attributes of an UPDATE message - where
NLRI is carried in either the IPv4-Unicast Advertised or Withdrawn
routes, or in the MP_REACH_NLRI or MP_UNREACH_NLRI attributes
[RFC2858], it is not possible to target error handling mechanisms
to specific NLRI, and hence session level mechanisms must be
utilised.
It is expected that those requirements outlined in Section 5 are
utilised to provide session-level handling of those errors identified
as 'critical'.
2.1.2. Semantic BGP Errors
Where a BGP message is correctly formed, a number of cases exist
whereby the contents of the UPDATE are not valid - in these cases,
this represents errors that can be identified to affect specific
NLRI. The following cases are expected to be classified a semantic
errors:
o Zero or invalid length errors in path attributes excluding those
containing NLRI, or where the length of all path attributes
contained within the UPDATE does not correspond to the total path
attributes length. In this case, the NLRI can be correctly
extracted, and hence acted upon.
o Messages where invalid data or flags are contained in a path
attribute that does not relate to the NLRI.
o UPDATE messages missing mandatory attributes, unrecognised non-
optional attributes or those that contain duplicate or invalid
attributes (be they unsupported or unexpected).
o Those messages where the NEXT_HOP, or MP_REACH next-hop values are
missing, length zero, or invalid for the relevant AFI/SAFI.
In these cases, it is expected that these errors can be handled
gracefully, following the requirements detailed in Section 3 and
Section 4 of this memo.
3. Avoiding use of NOTIFICATION 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.
skipping to change at page 10, line 18 skipping to change at page 11, line 18
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 In the general case, the consistency of the BGP RIB can be recovered
BGP speaker is aware that some routing information was not able to be by re-requesting the entire Adj-RIB-Out of a remote BGP speaker is
processed - due to the fact that an UPDATE message was not parsed re-advertised. A mechanism to achieve this re-advertisement is
correctly. If the 'treat-as-withdraw' mechanism described within defined within the ROUTE-REFRESH specification [RFC2918]. It is
Section 3 is utilised, it is also possible for the local BGP speaker envisaged that by requesting a refresh of all NLRI advertised by a
to have determined the set of NLRI for which an erroneous UPDATE BGP speaker, any NLRI which has been withdrawn due to being contained
message was received. In this scenario, by utilising targeted within an invalid UPDATE message is re-learnt. Where a ROUTE REFRESH
mechanisms to re-request the specific NLRI that was unreachable, this is used to directly perform a consistency check between the Adj-RIB-
routing information can be re-transmitted from the remote BGP Out of a remote device, and the Adj-RIB-In of the local BGP speaker,
speaker. Such a request requires extension to the existing BGP-4 a demarcation between the ROUTE-REFRESH, and normal UPDATE messages
protocol, in terms of specific UPDATE generation filters with a is required (in order that an "end" of the refresh can be used to
identify any 'stale' NLRI) - [I-D.keyur-bgp-enhanced-route-refresh]
provides a means by which the ROUTE-REFRESH mechanism can be extended
to meet this requirement.
Whilst re-advertisement of the whole BGP RIB provides a means by
which withdrawn NLRI can be re-advertised, there are some scaling
implications that must be considered. In the case that a ROUTE-
REFRESH is generated, all NLRI must be re-packed into UPDATE messages
and advertised by one speaker on the BGP session, whilst the other
must receive all UPDATE messages, and validate the RIB's consistency.
Clearly, it is advantageous to avoid this work where possible.
It is envisaged that during routing inconsistencies caused by
utilising the 'treat-as-withdraw' mechanism, the local 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 correctly.
Since this mechanism (as discussed in Section 3) requires the local
BGP speaker to have determined the set of NLRI for which an erroneous
UPDATE message was received, it is possible to use a targeted
mechanisms to re-request the specific NLRI that was contained within
the erroneous UPDATE message. By re-requesting, this provides the
remote BGP speaker an opportunity to re-transmit the NLRI - possibly
providing an opportunity to leverage alternative methods to build the
UPDATE message. Such a request requires extension to the existing
BGP-4 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.
In addition to such cases where specific routing information is known
to be erroneous, the more general case where either a large amount of
the Adj-RIB-In is contained in UPDATE messages subject to treat-as-
withdraw, or the specific prefixes are unknown to the local BGP
speaker must be considered. In this case, there is a requirement for
a BGP speaker to re-request the entire RIB advertised by a remote
neighbour. In this case, where such re-advertisement is required, it
is envisaged that a ROUTE-REFRESH as per the description in [RFC2918]
is utilised. [I-D.keyur-bgp-enhanced-route-refresh] provides a means
by which the ROUTE-REFRESH mechanism can be extended in order to meet
this requirement.
It is of particular note for both means of recovering RIB consistency It is of particular note for both means of recovering RIB consistency
described that these are effective only when considering transitive described that these are effective only when considering transitive
errors within an implementation - for instance, should an RFC errors within an implementation - for instance, should an RFC
interpretation error within an implementation be present, regardless interpretation error within an implementation be present, regardless
of the number of times a specific UPDATE is generated, it is likely of the number of times a specific UPDATE is generated, it is likely
that this error condition will persist. For this reason, there is an that this error condition will persist (as it may with the existing
behaviour defined by [RFC4271]). For this reason, there is an
requirement to consider the means by which such consistency recovery requirement to consider the means by which such consistency recovery
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.
skipping to change at page 12, line 50 skipping to change at page 13, line 50
mechanism described in [RFC4724]. Since the operational requirement mechanism described in [RFC4724]. Since the operational requirement
in this case is to provide a means to achieve a complete session in this case is to provide a means to achieve a complete session
restart without disrupting the forwarding path of those prefixes in restart without disrupting the forwarding path of those prefixes in
use within a BGP speaker's RIB, it is expected that utilising a use within a BGP speaker's RIB, it is expected that utilising a
procedure similar to the Graceful Restart mechanism meets the error procedure similar to the Graceful Restart mechanism meets the error
handling requirement. By responding to an error condition (repeated handling requirement. By responding to an error condition (repeated
or otherwise) with a message indicating that an error that cannot be or otherwise) with a message indicating that an error that cannot be
handled has occurred, forcing session reset, whilst retaining handled has occurred, forcing session reset, whilst retaining
forwarding information within the RIB allows forwarding to all forwarding information within the RIB allows forwarding to all
prefixes within a system's RIB to continue, whilst the session prefixes within a system's RIB to continue, whilst the session
restarts. By placing a time bound on the restart lifetime, should an restarts. It is envisaged that the additional complexity introduced
error condition not be transient - for example, should an error have by the introduction of such a mechanism can be limited by extending
occurred with the BGP process, rather than a specific of the BGP existing BGP messages - one such approach is proposed in
session - the remote BGP speaker is still detected as an invalid
device for forwarding. [I-D.keyupate-idr-bgp-gr-notification]. By placing a time bound on
the restart lifetime, should an error condition not be transient -
for example, should an error have occurred with the BGP process,
rather than a specific of the BGP session - the remote BGP speaker is
still detected as an invalid device for forwarding.
It should, however, be noted that a protocol enhancement meeting this It should, however, be noted that a protocol enhancement meeting this
requirement is not able to solve all error conditions - however, a requirement is not able to solve all error conditions - however, a
complete restart of the BGP and TCP session between two BGP speakers complete restart of the BGP and TCP session between two BGP speakers
implements an identical recovery mechanism to that which is achieved implements an identical recovery mechanism to that which is achieved
by the existing behaviour. Where an error condition such as memory by the existing behaviour. Where an error condition such as memory
or configuration corruption has occurred in a BGP implementation, it or configuration corruption has occurred in a BGP implementation, it
is expected that a mechanism meeting this requirement continues to is expected that a mechanism meeting this requirement continues to
detect this, by means of a bound on time for session restart to detect this, by means of a bound on time for session restart to
occur. Whilst there may be some consideration that packets continue occur. Whilst there may be some consideration that packets continue
skipping to change at page 14, line 17 skipping to change at page 15, line 17
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
RIB on a device are no longer reachable from a BGP speaker, or indeed RIB on a device are no longer reachable from a BGP speaker, or indeed
an AS, that some mechanism to determine the cause is available to an an AS, that some visibility of this situation, alongside a mechanism
operator. Whilst, to some extent, this can be solved by mandating a to determine the cause is available to an operator. Whilst, to some
sub-requirement of each of the aforementioned requirements that a BGP extent, this can be solved by mandating a sub-requirement of each of
speaker must log where such errors occur, and are hence handled, this the aforementioned requirements that a BGP speaker must log where
does not solve all cases. In order to clarify this requirement, the such errors occur, and are hence handled, this does not solve all
example of the transmission of an erroneous Optional Transitive cases. In order to clarify this requirement, the example of the
attribute can be considered. Since, by definition, there is no transmission of an erroneous Optional Transitive attribute can be
requirement for all BGP speakers to parse such an attribute, a considered. Since, by definition, there is no requirement for all
receiving router may treat NLRI as withdrawn based on an erroneous BGP speakers to parse such an attribute, a receiving router may treat
attribute not examined by its neighbour. In this case, the upstream NLRI as withdrawn based on an erroneous attribute not examined by its
device or network, propagating the UPDATE, has no visibility of this neighbour. In this case, the upstream device or network, propagating
error. Operationally, however, it is of interest to the upstream the UPDATE, has no visibility of this error. Operationally, however,
router operator that such invalid information was propagated. it is of interest to the upstream router operator that such invalid
information was propagated.
The requirement for logging of error conditions in transmitted BGP The requirement for logging of error conditions in transmitted BGP
messages, which are visible to only the receiver, cannot be achieved messages, which are visible to only the receiver, cannot be achieved
by any existing BGP message, or capability. It is envisaged that by any existing BGP message, or capability. It is envisaged that
each erroneous event should be transmitted to the remote peer - each erroneous event should be transmitted to the remote peer -
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
skipping to change at page 15, line 32 skipping to change at page 16, line 33
relate to the load generated on the BGP speaker in question, relate to the load generated on the BGP speaker in question,
however, it must be considered that in the case of an erroneous however, it must be considered that in the case of an erroneous
UPDATE being received, and the 'treat-as-withdraw' mechanism being UPDATE being received, and the 'treat-as-withdraw' mechanism being
utilised, where the erroneous path is removed from the Loc-RIB, utilised, where the erroneous path is removed from the Loc-RIB,
there is likely to be a requirement to generate UPDATE messages there is likely to be a requirement to generate UPDATE messages
withdrawing the prefix from all further BGP speakers to which the withdrawing the prefix from all further BGP speakers to which the
prefix is advertised. The load generated by the generation of prefix is advertised. The load generated by the generation of
such UPDATEs is likely to be much greater than that of such UPDATEs is likely to be much greater than that of
transmitting error information via a logging message type back to transmitting error information via a logging message type back to
the speaker from which it was received. It is envisaged that the speaker from which it was received. It is envisaged that
light-weight BGP message-based signalling mechanisms such as light-weight BGP message-based signalling mechanisms such as the
[I-D.ietf-idr-advisory] provide a suitable means to satisfy this ADVISORY message types detailed in
requirement. [I-D.frs-bgp-operational-message] provide a suitable means to
satisfy this requirement.
o Additional Diagnostic Capabilities for BGP - In a number of cases, o Additional Diagnostic Capabilities for BGP - In a number of cases,
there is an operational requirement to further debug erroneous BGP there is an operational requirement to further debug erroneous BGP
UPDATE messages, along with the particulars of the state of a BGP UPDATE messages, along with the particulars of the state of a BGP
speaker. For instance, where an invalid BGP UPDATE message is speaker. For instance, where an invalid BGP UPDATE message is
transmitted between two BGP speakers, the exact format of the transmitted between two BGP speakers, the exact format of the
UPDATE message is of interest to an operator, as this information UPDATE message is of interest to an operator, as this information
provides a clear indication of an message considered to be provides a clear indication of an message considered to be
erroneous by the BGP speaker to which it was transmitted. In this erroneous by the BGP speaker to which it was transmitted. In this
case, it is considered of great utility that the entire UPDATE case, it is considered of great utility that the entire UPDATE
message is transmitted back to the advertising speaker, in order message is transmitted back to the advertising speaker, in order
to allow for further debugging to occur. Whilst such information to allow for further debugging to occur. Whilst such information
is particularly useful to an operator, it clearly provides is particularly useful to an operator, it clearly provides
information that is not key to protocol operation - for this information that is not key to protocol operation - for this
reason, it is expected that some of the concerns regarding the reason, it is expected that some of the concerns regarding the
additional complexity, and load that a BGP speaker is subjected to additional complexity, and load that a BGP speaker is subjected to
is not acceptable. For this reason, it is required that where is not acceptable. For this reason, it is required that where
mechanisms are developed to support this requirement, messages of mechanisms are developed to support this requirement, messages of
this nature can be supported both within an existing BGP session, this nature can be supported both within an existing BGP session,
and via a dedicated separate session, be it BGP carrying messages and via a dedicated separate session, be it BGP carrying messages
such as DIAGNOSTIC [I-D.raszuk-bgp-diagnostic-message] or ADVISORY such as those defined in [I-D.frs-bgp-operational-message] or a
[I-D.ietf-idr-advisory] or a dedicated monitoring protocol akin to dedicated monitoring protocol akin to BMP described in
BMP described in [I-D.ietf-grow-bmp]. [I-D.ietf-grow-bmp].
Whilst the operational requirement for such monitoring tools to allow Whilst the operational requirement for such monitoring tools to allow
for visibility into BGP is clearly agreed upon, the means by which for visibility into BGP is clearly agreed upon, the means by which
such messages are transmitted between two BGP speakers is likely to such messages are transmitted between two BGP speakers is likely to
be dependent upon both the positions of the speakers in question (for be dependent upon both the positions of the speakers in question (for
instances, the requirements for such a protocol may differ where a instances, the requirements for such a protocol may differ where a
session is between two ASBRs under separate administration). The session is between two ASBRs under separate administration). The
introduction of additional message types to the BGP protocol clearly introduction of additional message types to the BGP protocol clearly
introduces further complexity - and leaves room for further introduces further complexity - and leaves room for further
implementation and standardisation errors that may compromise the implementation and standardisation errors that may compromise the
skipping to change at page 21, line 5 skipping to change at page 21, line 10
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.1. Reducing the Network Impact of Session Teardown
In some cases, where repeated erroneous UPDATE messages are received
on a BGP-4 session, it is desirable that a BGP speaker disconnects
completely from the remote peer without performing a restart, in
order to avoid the control-plane overhead of repeated session
establishment, and subsequent reset events. This behaviour may be
required after a per-session flag indicating erroneous behaviour is
set, as discussed in Section 7. The BGP-4 specification presented in
[RFC4271] achieves such a session shutdown by sending a NOTIFICATION
message, however, this has the net result that all downstream BGP
speakers (i.e. those to whom the NLRI carried over the now ceased BGP
session was readvertised) must withdraw this NLRI from their RIB, and
perform a best-path selection if required. In some cases, there may
be no alternate path being available, and hence a period of time for
which no valid BGP route exists. Particularly, this is very likely
to occur where an upstream BGP speaker performs a best-path selection
and advertises only a single path to its neighbours - there is a
requirement for the upstream speaker to perform a best-path
selection, and re-advertise a new set of NLRI before the downstream
system is able to converge to a new path. It should be noted that
where UPDATE messages withdrawing NLRI are not subject to the BGP
session's configured MinRouteAdvertisementInterval (MRAI) [RFC4271],
but re-advertisements are, this may result in a BGP speaker being
without a path for a period up to the MRAI.
Clearly, it is advantageous to avoid this period of time for which
there may be no reachability for a set of NLRI, especially since the
BGP speaker terminating a particular session is doing so due to a
particular error handling policy. The graceful shutdown mechanism
detailed in [I-D.francois-bgp-gshut] provides a mechanism by which a
BGP speaker is able to signal that a set of NLRI is to be withdrawn,
and hence allow downstream systems to pre-emptively perform a best-
path selection, and hence advertise new reachability information in a
make-before-break manner.
It is therefore envisaged, that where a session is to be shutdown,
based on a trigger relating to erroneous UPDATE messages being
received (be they repeated or not) that the graceful shutdown
procedure in utilised, so as to reduce the forwarding impact of NLRI
received on the session being withdrawn.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. 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
skipping to change at page 23, line 7 skipping to change at page 24, line 7
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 6 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.
10. Acknowledgements 10. Acknowledgements
The author would like to thank Shane Amante, Bruno Decraene, Rob The author would like to thank the following network operators for
Evans, David Freedman, Tom Hodgson, Sven Huster, Jonathan Newton, their insight, and valuable input in defining the requirements for a
Neil McRae, Thomas Mangin, Tom Scholl and Ilya Varlashkin for their variety of operational deployments of the BGP-4 protocol; Shane
review and valuable feedback. Amante, Bruno Decraene, Rob Evans, David Freedman, Tom Hodgson, Sven
Huster, Jonathan Newton, Neil McRae, Thomas Mangin, Tom Scholl and
Ilya Varlashkin.
In addition, many thanks are extended to Jeff Haas, Wim Hendrickx,
Alton Lo, Keyur Patel, John Scudder, Adam Simpson and Robert Raszuk
for their expertise relating to implementations of the BGP-4
protocol.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.chen-ebgp-error-handling] [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
Chen, E., Mohapatra, P., and K. Patel, "Revised Error "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
Handling for BGP Updates from External Neighbors",
draft-chen-ebgp-error-handling-00 (work in progress),
September 2010.
[I-D.ietf-grow-bmp]
Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring
Protocol", draft-ietf-grow-bmp-05 (work in progress),
December 2010.
[I-D.ietf-idr-advisory]
Scholl, T., Scudder, J., Steenbergen, R., and D. Freedman,
"BGP Advisory Message", draft-ietf-idr-advisory-00 (work
in progress), October 2009.
[I-D.ietf-idr-optional-transitive]
Scudder, J. and E. Chen, "Error Handling for Optional
Transitive BGP Attributes",
draft-ietf-idr-optional-transitive-03 (work in progress),
September 2010.
[I-D.keyur-bgp-enhanced-route-refresh]
Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced
Route Refresh Capability for BGP-4",
draft-keyur-bgp-enhanced-route-refresh-02 (work in
progress), March 2011.
[I-D.raszuk-bgp-diagnostic-message]
Raszuk, R., Chen, E., and B. Decraene, "BGP Diagnostic
Message", draft-raszuk-bgp-diagnostic-message-02 (work in
progress), March 2011.
[I-D.zeng-one-time-prefix-orf]
Zeng, Q. and J. Dong, "One-time Address-Prefix Based
Outbound Route Filter for BGP-4",
draft-zeng-one-time-prefix-orf-01 (work in progress),
October 2010.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000. September 2000.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
skipping to change at page 25, line 25 skipping to change at page 25, line 38
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. 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.
11.2. Informational References 11.2. Informational References
[I-D.chen-ebgp-error-handling]
Chen, E., Mohapatra, P., and K. Patel, "Revised Error
Handling for BGP Updates from External Neighbors",
draft-chen-ebgp-error-handling-01 (work in progress),
September 2011.
[I-D.francois-bgp-gshut]
Francois, P., Decraene, B., pelsser, c., and C. Filsfils,
"Graceful BGP session shutdown",
draft-francois-bgp-gshut-01 (work in progress),
March 2009.
[I-D.frs-bgp-operational-message]
Raszuk, R., Shakir, R., and D. Freedman, "BGP OPERATIONAL
Message", draft-frs-bgp-operational-message-00 (work in
progress), July 2011.
[I-D.ietf-grow-bmp]
Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring
Protocol", draft-ietf-grow-bmp-05 (work in progress),
December 2010.
[I-D.ietf-idr-optional-transitive]
Scudder, J. and E. Chen, "Error Handling for Optional
Transitive BGP Attributes",
draft-ietf-idr-optional-transitive-03 (work in progress),
September 2010.
[I-D.keyupate-idr-bgp-gr-notification]
Patel, K., Fernando, R., Scudder, J., and J. Haas,
"Notification Message support for BGP Graceful Restart",
draft-keyupate-idr-bgp-gr-notification-00 (work in
progress), July 2011.
[I-D.keyur-bgp-enhanced-route-refresh]
Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced
Route Refresh Capability for BGP-4",
draft-keyur-bgp-enhanced-route-refresh-02 (work in
progress), March 2011.
[I-D.zeng-one-time-prefix-orf]
Zeng, Q. and J. Dong, "One-time Address-Prefix Based
Outbound Route Filter for BGP-4",
draft-zeng-one-time-prefix-orf-01 (work in progress),
October 2010.
[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 London
UK UK
 End of changes. 18 change blocks. 
109 lines changed or deleted 262 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/