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]