idnits 2.17.1 draft-chen-ebgp-error-handling-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4271, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4271, updated by this document, for RFC5378 checks: 2006-01-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 8, 2010) is 4972 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Chen 3 Internet Draft P. Mohapatra 4 Updates: 4271 (if approved) K. Patel 5 Intended Status: Standards Track Cisco Systems 6 Expiration Date: March 9, 2011 September 8, 2010 8 Revised Error Handling for BGP Updates from External Neighbors 9 draft-chen-ebgp-error-handling-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on March 9, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 In this document we partially revise the error handling of an UPDATE 52 message from an external BGP neighbor. The essence of the revision 53 is to avoid resetting an external BGP session by using the "treat- 54 as-withdraw" approach when the whole NLRI field of a malformed UPDATE 55 message can be parsed. 57 1. Introduction 59 The base BGP specification [RFC4271] requires that a BGP session be 60 reset when an UPDATE message containing a malformed attribute is 61 received. This behavior is undesirable in the case of optional 62 transitive attributes as has been discussed and revised in [OPT- 63 TRANS]. 65 However, there are other situations where the behavior is also 66 undesirable, but are outside the scope of [OPT-TRANS]. For example, 67 there have been a few occurrences in the field where the AS-PATH 68 attribute is malformed for a small number of routes. Resetting the 69 BGP session would impact all the other valid routes in these cases. 71 Our goal is to minimize the scope of the network that is affected by 72 a malformed UPDATE message, and also to limit the impact to only the 73 routes involved. The constrain is that the protocol correctness must 74 not be violated. 76 In this document we partially revise the error handling of an UPDATE 77 message from an external BGP neighbor. The essence of the revision 78 is to avoid resetting an external BGP session by using the "treat- 79 as-withdraw" approach specified in [OPT-TRANS] when the whole NLRI 80 field of a malformed UPDATE message can be parsed. 82 1.1. Specification of Requirements 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Revision to Base Specification 90 The revised error handling specified in this section is applicable 91 only for processing an UPDATE message from an external BGP neighbor. 93 The error handling of the following case described in Section 6.3 of 94 [RFC4271] remains unchanged: 96 If the Withdrawn Routes Length or Total Attribute Length 97 is too large (i.e., if Withdrawn Routes Length + Total Attribute 98 Length + 23 exceeds the message Length), then the Error Subcode 99 MUST be set to Malformed Attribute List. 101 The error handling of all other cases described in Section 6.3 of 102 [RFC4271] that specify a sesion reset is conditionally revised as 103 follows. 105 If a path attribute in an UPDATE message from an external BGP 106 neighbor is determined to be malformed, the message containing that 107 attribute SHOULD be treated as though all contained routes had been 108 withdrawn ("treat-as-withdraw") when the whole NLRI field in the 109 message can be parsed. 111 One exception is that the "attribute discard" approach [OPT-TRANS] 112 SHOULD be used to handle a malformed optional transitive attribute 113 for which the "attribute discard" approach is specified. 115 A BGP speaker MUST provide debugging facilities to permit issues 116 caused by malformed UPDATE messages to be diagnosed. At a minimum, 117 such facilities SHOULD include logging an error when such an 118 attribute is detected. The malformed UPDATE message SHOULD be 119 analyzed, and the root cause SHOULD be investigated. 121 3. Parsing of NLRI Fields 123 As described in [OPT-TRANS], we observe that in order to use the 124 "treat-as-withdraw" approach for a malformed UPDATE, the NLRI field 125 and/or MP_REACH and MP_UNREACH [RFC4760] attributes need to be 126 successfully parsed. If this were not possible, the UPDATE would 127 necessarily be malformed in some other way beyond the scope of this 128 document and therefore, the procedures of [RFC4271] would continue to 129 apply. 131 To facilitate the determination of the NLRI field in an UPDATE with 132 malformed attributes, we strongly RECOMMEND that the MP_REACH or 133 MP_UNREACH attribute (if present) be encoded as the very first path 134 attribute in an UPDATE. 136 Traditionally the NLRIs for the IPv4 unicast address family are 137 carried immediately following all the attributes in an UPDATE 138 [RFC4271]. When such an UPDATE is received, we observe that the NLRI 139 field can be determined using the "Message Length" and the "Total 140 Attribute Length" (when they are consistent) carried in the message 141 instead of relying on the length of individual attributes in the 142 message. 144 Furthermore, it is observed that the NLRIs for the IPv4 unicast 145 address family can also be carried in the MP_REACH attribute of an 146 UPDATE when the IPV4 unicast address family capability is shared 147 (i.e., both advertised and received) over a BGP session. For the 148 same sake of better debugging and fault handling, we also RECOMMEND 149 that the MP_REACH attribute be used and be placed as the very first 150 path attribute in an UPDATE in this case. 152 4. Discussion 154 As discussed in [OPT-TRANS], the approach of "treat-as-withdraw" is 155 not always safe to use. In the case of internal BGP sessions, the 156 resolution of recursive nexthops can result in forwarding loops and 157 blakholes when the BGP speakers inside a network have inconsistent 158 routing information. 160 Depending on the network topology, the routing table, routes 161 involved, and whether "tunnels" are used inside a network, the 162 approach of "treat-as-withdraw" may work for internal BGP sessions 163 only in some specific cases. Thus it may be deployed for internal 164 BGP sessions only as a temporary measure to stop continuous session 165 flaps due to malformed UPDATE messages. Such deployment must be 166 carefully evaluated on a case-by-case basis. 168 5. IANA Considerations 170 This document makes no request of IANA. 172 6. Security Considerations 174 TBD 176 7. Acknowledgments 178 We would like to thank Robert Raszuk, Naiming Shen and Tony Li for 179 their review and discussions. 181 8. References 183 8.1. Normative References 185 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 186 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 187 2006. 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, March 1997. 192 8.2. Informative References 194 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 195 "Multiprotocol Extensions for BGP-4", RFC 4760, 196 January 2007. 198 [OPT-TRANS] Scudder, J. and E. Chen, "Error Handling for Optional 199 Transitive BGP Attributes", Work in Progress, March 2010. 201 9. Authors' Addresses 203 Enke Chen 204 Cisco Systems, Inc. 205 170 W. Tasman Dr. 206 San Jose, CA 95134 208 EMail: enkechen@cisco.com 210 Pradosh Mohapatra 211 Cisco Systems, Inc. 212 170 W. Tasman Dr. 213 San Jose, CA 95134 214 EMail: pmohapat@cisco.com 216 Keyur Patel 217 Cisco Systems, Inc. 218 170 W. Tasman Dr. 219 San Jose, CA 95134 221 EMail: keyupate@cisco.com