IDR Working Group R. Raszuk
Internet-Draft E. Chen
Intended status: Standards Track Cisco Systems
Expires: September 12, 2011 B. Decraene
France Telecom
March 11, 2011
BGP Diagnostic Message
draft-raszuk-bgp-diagnostic-message-02
Abstract
BGP protocol lacks self diagnostic tools which would allow for
monitoring and detection of any possible bgp state database
differences between BGP_RIB_Out of the sender and BGP_RIB_In of the
receiver over BGP peering session. It also lacks of build in
mechanism to inform peer about subset of prefixes received over
session which experienced some errors and which per protocol
specification either resulted in attribute drop or "treat-as-
withdraw" action.
The intention of this document is to start a new class of work which
will make BGP protocol and therefor assuring services constructed
with the help of BGP protocol to become much more reliable and
robust.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Raszuk, et al. Expires September 12, 2011 [Page 1]
Internet-Draft bgp-diagnostic-message March 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BGP diagnostic message . . . . . . . . . . . . . . . . . . . . 4
3.1. BGP DIAGNOSTIC Message Encoding . . . . . . . . . . . . . 4
3.2. BGP DIAGNOSTIC Message TLVs . . . . . . . . . . . . . . . 5
3.2.1. Operational TLVs . . . . . . . . . . . . . . . . . . . 6
3.2.2. BGP database counters exchange . . . . . . . . . . . . 9
3.2.3. Diagnostics for encoding errors in BGP messages . . . 10
3.2.4. AFI/SAFI signaling when malformed update . . . . . . . 12
3.2.5. Prefix specific BGP debugging . . . . . . . . . . . . 12
3.2.6. Intra-domain bgp decision monitoring . . . . . . . . . 14
3.2.7. Exchange of installed Route Target filters . . . . . . 15
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Capability negotiation . . . . . . . . . . . . . . . . . . . . 16
6. Security considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Raszuk, et al. Expires September 12, 2011 [Page 2]
Internet-Draft bgp-diagnostic-message March 2011
1. Introduction
In this document we will first define a new diagnostic communication
channel in the form of new BGP message then construct the set of
basic message encoding to be used for simple diagnostic self test
routines periodically exchanged between BGP speakers. We will also
define set of other TLVs which can be very useful in precise
description of prefixes affected by various cases of BGP session
malfunctions.
The goal of this document is to provide the background which will in
turn allow for very easy extensibility once new needs and new BGP
diagnostic ideas surface.
2. Applications
Authors would like to propose four main applications which BGP
Diagnostic TLVs are designed to address. New TLVs can be easily
added to enhance further current applications or to propose new
applications.
The set of TLVs is organized in the following application groups:
General TLVs used for operational purposes of the described
mechanism.
Set of TLVs designed to carry information about BGP state across
BGP peers that include per neighbor counters and global counters.
There are two modes this functionality can be used - on demand by
explicit query as well as periodic in an automated mode. The
scope of messages is to be able to operate both on the iBGP as
well as eBGP boundaries. It is in the control of the operator to
decide which set of information would be send to a given set of
peers.
Messages which operate in an automated push mode (as long as peer
negotiated listen capability for them) and are designed to inform
BGP peer on the list of impacted NLRIs which were received along
with malformed attribute or within malformed update message.
Following recommendation from MP-BGP4 RFC4760 next group of
messages are used to indicate which AFI/SAFIs were disabled for
any further processing by BGP peer due to detection of an
incorrect attribute present in the BGP Update message.
In number of troubleshooting efforts in real networks it is often
very helpful to verify state of a given prefix in the neighboring
Raszuk, et al. Expires September 12, 2011 [Page 3]
Internet-Draft bgp-diagnostic-message March 2011
router's BGP database. This is particularly useful on the EBGP
boundaries where there is no CLI/SNMP access to the router.
Authors define a new way of query peer's BGP for the state of
particular prefix.
Last set of messages is an attempt to allow for intra-domain
better analysis of the BGP best path selection tie break
decisions.
3. BGP diagnostic message
When defining any self test tool the critical element is to find a
right separation balance between the test object and testing
instruments.
For the vast majority of real BGP issues found in the life production
networks authors believe that the right balance is the definition of
new BGP message which could be exchanged along with any negotiated
AFI/SAFI between those BGP speakers which will during initial OPEN
message exchange new BGP diagnostic message capability.
The two extreme alternatives which were considered were the
definition of new BGP attribute which may inherit and share potential
issues of given BGP address family it is designed to diagnose and on
the other extreme to build a separate and independent network
diagnostic protocol. The use of BGP message seems to provide
sufficient isolation from any service address family and is much
easier to deploy then enabling an entire new intra and inter-domain
protocol. Another very important issue with using any other protocol
for detection of potential differences of BGP databases state is lack
of synchronization with BGP UPDATE messages. This alone in the
continuously churning BGP environment would not allow for any
benefit.
3.1. BGP DIAGNOSTIC Message Encoding
BGP message as defined in RFC 4271 consists of a fixed-size header
followed by two octet length field and one octet of type value. RFC
4271 limits maximum message size to 4096 octets. As one of the
applications of BGP Diagnostic message is to be able to carry entire
potentially malformed BGP message this specification extends the
maximum size of BGP Diagnostic message to be always 128 octets bigger
then any other BGP Message. Considering the current RFC 4271 maximum
BGP message size to be 4096 octets maximum size of BGP diagnostic
message would be 4224 octets.
For the purpose of diagnostic message information encoding we will
Raszuk, et al. Expires September 12, 2011 [Page 4]
Internet-Draft bgp-diagnostic-message March 2011
use one or more Type-Length-Value containers where each TLV will have
the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable size TLV value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DIAGNOSTIC message TLV Format
Type - 2 octet value indicating the TLV type
Length - 2 octet value indicating the TLV length in octets
Value - Variable length value field depending on the type of
the TLVs carried.
To work around continued BGP churn issue some types of TLVs will need
to contain a sequence number to correlate request with associated to
it replies. The sequence number will consist of 8 octets and will be
of form: 4 octet bgp_router_id + local 4 octet number. When local 4
octet number reaches 0xFFFF it should restart from 0x0000.
Typical application scenario for use of sequence number is to include
it in the diagnostic request message and during reply to copy it into
reply messages triggered by such request message.
3.2. BGP DIAGNOSTIC Message TLVs
This document defines the following diagnostic TLV types:
* Operational TLVs
* BGP database counters exchange
* Diagnostics for encoding errors in BGP messages
* AFI/SAFI signaling when malformed update
* Prefix specific BGP debugging
* Intra-domain bgp decision monitoring
Raszuk, et al. Expires September 12, 2011 [Page 5]
Internet-Draft bgp-diagnostic-message March 2011
* Exchange of Route Target filters
* Errors and warnings detected when validating BGP paths and prefixes
3.2.1. Operational TLVs
Type 1 - Diagnostic Message Periodic Request
Length - 2 octets - variable value
Value (N x 2 octets):
TLV type - 2 octets
Use: To indicate the request to periodically receive listed TLV
information. TLV type of 0xFFFF indicates request to receive
all available diagnostic TLVs from the peer.
Type 2 - Max frequency permitted
Length - 2 octets - variable value
Value (N x 4 octets):
TLV type - 2 octets
Frequency value in seconds two octets 0..65535
Special values:
0 - never send given diagnostic TLV
65535 - no TLV inter-gap minimum set
Use: To indicate in seconds the maximum frequency given TLV
may be periodically sent to the bgp speaker
Raszuk, et al. Expires September 12, 2011 [Page 6]
Internet-Draft bgp-diagnostic-message March 2011
Type 3 - Diagnostic Message Query
Length - 2 octets - variable value
Sequence number - 8 octets
Value (N x 2 octets):
TLV type - 2 octets
Use: To interactively (during debugging/troubleshooting) request
to receive listed TLV information. TLV type of 0xFFFF
indicates request to receive all available diagnostic TLVs
from the peer. TLV of type 0x0000 indicates request to
receive a list of all enabled and available diagnostic
TLV types from the peer towards querying BGP speaker. The
support of this TLV type is mandatory.
Type 4 - Counter's reset request
Length - 2 octets - variable value
Value (N x 2 octets):
TLV type - 2 octets - List of TLVs subject to counter's reset.
Use: To request rest of per neighbor counters of a given TLV
type. TLV type of 0xFFFF indicates request to zero all
per neighbor counters.
Raszuk, et al. Expires September 12, 2011 [Page 7]
Internet-Draft bgp-diagnostic-message March 2011
Type 5 - Not supported TLV reply
Length - 2 octets - variable value
Value (N x 3 octets):
TLV type - 2 octets - TLV that is not supported by the peer
but where part of TLV Request or TLV Query message
Error Code - 1 octet - Error code
Error codes:
0x01 - Wrong TLV value
0x02 - TLV not supported for this peer
0x03 - Max query frequency exceeded
0x04 - Administratively disabled
Use: To indicate to the peer that the TLV he has requeste
either in TLV Request or in TLV Query message is not
supported. The support of this TLV type is mandatory.
Type 6 - Enabled and supported TLV types
Length - 2 octets - variable value
Value (N x 2 octets):
TLV type - 2 octets - TLV that is enabled and supported
by the peer
Use: To indicate to the peer that the enclosed list of TLVs
can be requested either in TLV Request or in TLV Query
messages. The support of this TLV type is mandatory.
Raszuk, et al. Expires September 12, 2011 [Page 8]
Internet-Draft bgp-diagnostic-message March 2011
3.2.2. BGP database counters exchange
Type 7 - Number of Reachable Prefixes Transmitted/Received
Length - 2 octets - variable value
Sequence number - 8 octets
Value (N x 11 octets):
AFI/SAFI - 3 octets
Number of prefixes transmitted - 4 octets
Number of prefixes received - 4 octets
Use: To indicate number of reachable prefixes exchanged for
a given AFI/SAFI between two bgp speakers. This message
can be sent only based on the remote query Type 3 which
contains the query sequence number to be placed in the
reply.
Type 8 - Number of prefixes in BGP_RIB_Out
Length - 2 octets - variable value
Value (N x 7 octets):
AFI/SAFI - 3 octets
Number of prefixes 4 octets
Use: To indicate number of prefixes kept in BGP_RIB_Out between
bgp speakers for a given AFI/SAFI between two bgp speakers.
Type 9 - Number of paths in BGP_RIB_Out
Length - 2 octets - variable value
Value (N x 6 octets):
AFI/SAFI - 3 octets
Number of paths 4 octets
Use: To indicate number of paths kept in BGP_RIB_Out between bgp
speakers for a given AFI/SAFI between two bgp speakers.
Raszuk, et al. Expires September 12, 2011 [Page 9]
Internet-Draft bgp-diagnostic-message March 2011
Type 10 - Number of prefixes present in BGP_RIB
Length - 2 octets - variable value
Value (N x 6 octets):
AFI/SAFI - 3 octets
Number of prefixes 4 octets
Use: To indicate number of prefixes kept in BGP RIB for a given
AFI/SAFI.
Type 11 - Number of paths present in BGP_RIB
Length - 2 octets - variable value
Value (N x 7 octets):
AFI/SAFI - 3 octets
Number of prefixes 4 octets
Use: To indicate number of paths kept in BGP RIB for a given
AFI/SAFI.
3.2.3. Diagnostics for encoding errors in BGP messages
Type 12 - Reachable prefixes present in dropped attribute UPDATE msg
Length - 2 octets - variable value
Value (N octets):
AFI/SAFI - 3 octets
1 .. M - List of prefixes
Use: To list reachable prefixes present in the update message
where optional transitive attribute with partial bit set
was malformed and has been removed from the update message.
Prefix encoding should follow given AFI/SAFI definition.
Raszuk, et al. Expires September 12, 2011 [Page 10]
Internet-Draft bgp-diagnostic-message March 2011
Type 13 - Unreachable prefixes present in dropped attribute UPDATE msg
Length - 2 octets - variable value
Value (N octets):
AFI/SAFI - 3 octets
1 .. M - List of prefixes
Use: To list unreachable prefixes present in the update message
where optional transitive attribute with partial bit set
was malformed and has been removed from the update message.
Prefix encoding should follow given AFI/SAFI definition.
Type 14 - Reachable prefixes present in malformed UPDATE msg
Length - 2 octets - variable value
Value (N octets):
AFI/SAFI - 3 octets
1 .. M - List of prefixes
Use: To list reachable prefixes present in the malformed update
message which were subject to "treat-as-withdraw" behaviour.
Prefix encoding should follow given AFI/SAFI definition.
Type 15 - Entire malformed update message enclosure
Length - 2 octets - variable value
Sequence number - 8 octets
Value:
Malformed message
Use: Propagate the malformed message to the peer upon it's
request or at the event of error detection. That includes
propagation of messages which had malformed attribute,
unparsable content or any other abnormal encoding. If more
then a single message has been determined as malformed the
subsequent replies will contain the same sequence number
and should not be treated as an override.
Raszuk, et al. Expires September 12, 2011 [Page 11]
Internet-Draft bgp-diagnostic-message March 2011
3.2.4. AFI/SAFI signaling when malformed update
Type 16 - List of ignored AFI/SAFIs by the peer over given session
Length - 2 octets - variable value
Value (N octets):
1..M AFI/SAFI - 3 octets each
Use: To list those AFI/SAFIs which were detected to be malformed
by the peer and while session is up were transitioned to
IGNORE state.
Such case is inline with Multiprotocol Extensions
RFC 4760 as per it's section 7 Error Handling:
"For the duration of the BGP session over which the UPDATE
message was received, the speaker then SHOULD ignore all
the subsequent routes with that AFI/SAFI received over
that session".
3.2.5. Prefix specific BGP debugging
Type 17 - Prefix specific BGP query
Length - 2 octets - variable value
Value (N octets):
AFI/SAFI - 3 octets
Prefix under query
Prefix mask (optional)
Use: To query peer for the status of prefix under examination.
When prefix mask is present the request is for exact match.
When prefix mask is not present the request is for the
longest match. Prefix encoding should follow given AFI/SAFI
definition.
Raszuk, et al. Expires September 12, 2011 [Page 12]
Internet-Draft bgp-diagnostic-message March 2011
Type 18 - Prefix specific BGP response
Length - 2 octets - variable value
Value (N octets):
AFI/SAFI - 3 octets
Prefix under query
Prefix mask (optional)
Prefix status (1 octet)
Status:
0x01 - prefix not found in BGP table
0x02 - prefix in BGP table and active (in FIB)
0x03 - prefix in BGP table and not-active (not in FIB)
0x04 - administratively disabled
Use: To inform peer querying about the status of particular
prefix status. Prefix encoding should follow given AFI/SAFI
definition.
Type 19 - BGP attribute based prefix query
Length - 2 octets - variable value
Value (N octets):
AFI/SAFI - 3 octets
Query Parameters - 1 octet
BGP Attribute TLV
Defined Query Parameters:
Bit 0 - value 0 - Exact match
Bit 0 - value 1 - Partial match
Use: To query peer for the list of prefixes which paths contain
given BGP attribute. BGP attribute encoding should follow
given attribute's specification.
Raszuk, et al. Expires September 12, 2011 [Page 13]
Internet-Draft bgp-diagnostic-message March 2011
Type 20 - BGP attribute based prefix reply
Length - 2 octets - variable value
Value (N octets):
AFI/SAFI - 3 octets
Query Parameters - 1 octet
1 .. M - List of prefixes
Defined Query Parameters:
Bit 0 - value 0 - Exact match
Bit 0 - value 1 - Partial match
Use: To inform bgp peer about presence of set of prefixes
which contain with exact or partial match the BGP
Attribute as specified in the query. Prefix encoding
should follow given AFI/SAFI definition.
3.2.6. Intra-domain bgp decision monitoring
Type 21 - Number of IGP metric best path tie breaks executed
Length - 2 octets - variable value
Value (N x 7 octets):
AFI/SAFI - 3 octets
Number of tie breaks 4 octets
Use: To indicate number of prefixes with their best path selected
by tie break of IGP metric to their BGP next hop distance
step of BGP best path selection algorithm.
Type 22 - Number of BGP best path tie breaks in each selection step
Length - 2 octets - variable value
Value (N x 7 octets):
AFI/SAFI - 3 octets
Best path selection step N - Number of tie breaks 4 octets
Use: To indicate number of cases where in BGP best path selection
algorithm given step has been used as a tie break during
overall best path selection process for a given prefix.
Raszuk, et al. Expires September 12, 2011 [Page 14]
Internet-Draft bgp-diagnostic-message March 2011
3.2.7. Exchange of installed Route Target filters
Type 23 - Request for reception of route target filters
installed towards given peer by RFC4684
Length - 2 octets - variable value
Sequence number - 8 octets
Value (N x 7 octets):
AFI/SAFI - 3 octets
BGP Router ID of the peer - 4 octets
Use: To request reception of full table of route target
fiters installed towards listed BGP peer for a requested
AFI/SAFI. Single request may contain multiple pairs of
AFI/SAFIs and/or BGP Router IDs.
Type 24 - Reply containing all route target filters installed
towards given peer
Length - 2 octets - variable value
Sequence number - 8 octets
Value (7 + N * 12 or 24 octets):
AFI/SAFI - 3 octets
BGP Router ID of the peer - 4 octets
List of route targets - each 12 or 24 octets
Use: Allows for troubleshooting purposes to share list of
route targets installed for a given AFI/SAFI towards
indicated BGP peer. In the event that RT filtering
table size will not fit in single BGP Diagnostic
Message reply the subsequent reply should include
the same sequence number.
4. Operation
BGP implementation which supports DIAGNOSTIC message can support all
or subset of defined diagnostic types. The range of supported TLV
types will be signaled in the new BGP capability message during BGP
connection establishment phase.
The operation of this extension can be realized on a pool/query based
or push based principles. An implementation may provide, a timer to
periodically send selected Diagnostic types TLVs to the peer or to
the management station.
Raszuk, et al. Expires September 12, 2011 [Page 15]
Internet-Draft bgp-diagnostic-message March 2011
Similarly BGP peer may periodically or by manual cli request the
reception of selected or all of the defined diagnostic TLV types.
The received values are then compared against local counters. When
discrepancy is found operator is alarmed and further analysis should
follow. The repair actions is out of scope of this document.
Example:
Under some situations when determined that the discrepancy is
detected an automated or manual Route Refresh message can be
triggered with it's extension for Start_of_Refresh and End_of_Refresh
markers . That would allow for purge of any stalled data across two
BGP databases.
An important point which needs to be discussed is the exchange of
counter's values in light of continued BGP churn presence. As BGP is
never stable it is expected that any sort of described counters will
also be subject to continues value change making any comparison of
their values questionable.
There are three classes of counters defined in this document: sent
counters, received counters and current table state counters.
Only "sent" counters can be used for not correlated comparison and
problem detection between any two BGP speakers. They are not subject
to BGP churn issue due to the fact that DIAGNOSTIC messages would be
exchanged inline with BGP UPDATE messages on a given session. An
implementation must be able to freeze the received counters when
comparing or displaying the received "sent" counters from BGP peer.
Received counters send in the Diagnostic messages are only meaningful
in the context of explicit request trigger situation generated by the
BGP speaker. BGP speaker should stop transmitting any BGP message of
a given AFI/SAFI or freeze corresponding counter after sending
diagnostic message request to the peer and before reception of actual
diagnostic message reply. In order to correlate diagnostic message
requests with associated replies use of build in sequence numbers is
provided.
Table state counters (for example number of BGP RIB entries) are
exchanged only for informational reasons and they should not be
subject to comparison with any local counter values.
5. Capability negotiation
A BGP speaker that is willing to send or receive the BGP DIAGNOSTIC
Raszuk, et al. Expires September 12, 2011 [Page 16]
Internet-Draft bgp-diagnostic-message March 2011
Messages from its peer should advertise the new DIAGNOSTIC Messages
Capability to the peer using BGP Capabilities advertisement [BGP-
CAP]. A BGP speaker may send a DIAGNOSTIC message to its peer only
if it has received the DIAGNOSTIC message capability from its peer.
The Capability Code for this capability is specified in the IANA
Considerations section of this document.
The Capability Length field of this capability is 2 octets. The
Capability Value field consists of reserved flags field.
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Flags (2 octets) |
+------------------------------+
Figure 2: DIAGNOSTIC message BGP Capability Format
6. Security considerations
No new security issues are introduced to the BGP protocol by this
specification.
7. IANA Considerations
IANA is requested to allocate a type code for the DIAGNOSTIC message
from the BGP Message Types registry, as well as requesting a type
code for the new Diagnostic Message Capability negotiation from BGP
Capability Codes registry.
This document requests IANA to define and maintain a new registry
named: "DIAGNOSTIC Message Type Values". The reserved types are:
0x0000 0xFFFF. The allocation policy is on a first come first served
basis.
This document makes the following assignments for the DIAGNOSTIC
Message Type Values:
Raszuk, et al. Expires September 12, 2011 [Page 17]
Internet-Draft bgp-diagnostic-message March 2011
Type 1 - Diagnostic Message TLV(s) Request
Type 2 - Max frequency permitted
Type 3 - Diagnostic Message TLV(s) Query
Type 4 - Counter's reset request
Type 5 - Not supported TLV
Type 6 - Enabled and supported TLV types
Type 7 - Number of Reachable Prefixes Transmitted/Received
Type 8 - Number of prefixes in BGP_RIB_Out
Type 9 - Number of paths in BGP_RIB_Out
Type 10 - Number of prefixes present in BGP_RIB
Type 11 - Number of paths present in BGP_RIB
Type 12 - Reachable prefixes present in dropped attribute message
Type 13 - Unreachable prefixes present in dropped attribute message
Type 14 - Reachable prefixes present in malformed UPDATE message
Type 15 - Entire malformed update message enclosure
Type 16 - List of ignored AFI/SAFIs by the peer over given session
Type 17 - Prefix specific BGP query
Type 18 - Prefix specific BGP response
Type 19 - BGP attribute based prefix query
Type 20 - BGP attribute based prefix reply
Type 21 - Number of IGP metric best path tie breaks executed
Type 22 - Number of BGP best path tie breaks in each selection step
Type 23 - Request for reception of route target filters
Type 24 - Reply containing all route target filters installed
Type 25 - 65534 Free for future allocation.
Type 65535 - Reserved
8. Acknowledgments
Authors would like to thank Alton Lo for his valuable input.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Raszuk, et al. Expires September 12, 2011 [Page 18]
Internet-Draft bgp-diagnostic-message March 2011
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009.
9.2. Informative References
[I-D.retana-bgp-security-state-diagnostic]
Retana, A. and R. Raszuk, "BGP Security State Diagnostic
Message", draft-retana-bgp-security-state-diagnostic-00
(work in progress), March 2011.
[I-D.shakir-idr-ops-reqs-for-bgp-error-handling]
Shakir, R., "Operational Requirements for Enhanced Error
Handling Behaviour in BGP-4",
draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 (work
in progress), February 2011.
Authors' Addresses
Robert Raszuk
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
US
Email: raszuk@cisco.com
Enke Chen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
US
Email: enkechen@cisco.com
Bruno Decraene
France Telecom
38-40 rue du General Leclerc
Issi Moulineaux cedex 9 92794
France
Email: bruno.decraene@orange-ftgroup.com
Raszuk, et al. Expires September 12, 2011 [Page 19]