]> Orange

bruno.decraene@orange.com

HPE

jgs@juniper.net

rtg Internet Engineering Task Force bgp error-handling NLRI RFC 7606 partially revises the error handling for BGP UPDATE messages. It reduces the cases of BGP session reset by defining and using less impactful error handling approaches, such as attribute discard and treat-as-withdraw when applicable. The treat-as-withdraw approach requires that the entire NLRI field of the MP_REACH_NLRI attribute be successfully parsed. This typically means parsing errors in MP_REACH_NLRI cannot be handled by any means short of session reset. This is exacerbated by the use of non-key data within NLRI, which introduces parsing complexity and additional error cases. This specification defines a non-transitive BGP attribute, the "Treat-As-Withdraw Attribute", to encode NLRIs as per the format of MP_UNREACH_NLRI. This attribute is used to allow the treat-as-withdraw error-handling approach to be used in case an error in the MP_UNREACH_NLRI attribute prevents the parsing of its NLRIs. This document updates RFC 7606 by mandating that the Treat-As-Withdraw Attribute appear before the MP_REACH_NLRI (or any other) attribute in an UPDATE message.

Introduction According to the base BGP specification , a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset impacts not only routes with the offending attribute but also other valid routes exchanged over the session. revises BGP error handling, with the goal of minimizing the impact on routing of a malformed UPDATE message, while maintaining protocol correctness to the extent possible. For most BGP attributes, a malformed attribute may be handled using attribute discard or treat-as-withdraw. Both approaches preserve the routing of all the NLRIs not advertised in the affected BGP UPDATE message. However, as indicated in Section 3 of , treat-as-withdraw can only be used if the entire NLRI field of the MP_REACH_NLRI attribute is successfully parsed. This typically means parsing errors in MP_REACH_NLRI cannot be handled by any means short of session reset. allows the Border Gateway Protocol (BGP) to advertise general routing information in the Network Layer Reachability Information (NLRI) field of the UPDATE message. Some specifications, such as , , and carry both a key field and a non-key field in the NLRI. The key field is typically the real NLRI. The non-key field carries extra data that is NLRI-specific and hence not located in the BGP path attributes for packing optimization purposes. For example, carries the Prefix in the key field and one label (stack) in the non-key field. As another example, defines a BGP CAR SAFI explicitly carrying Key Fields and Non-Key Fields as a list of TLVs. In case of a BGP withdraw, the key is indicated in the MP_UNREACH_NLRI attribute to withdraw the unfeasible routes, while the non-key data is typically not encoded. This specification defines a new BGP non-transitive attribute, the "Treat-As-Withdraw Attribute", to carry the NLRIs using the simple and existing format of MP_UNREACH_NLRI. This attribute is used to allow the treat-as-withdraw error-handling approach to be used when there is an error in the MP_UNREACH_NLRI attribute that prevents the parsing of its NLRIs.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Treat-As-Withdraw Attribute The Treat-As-Withdraw attribute is an optional, non-transitive BGP path attribute with type code TBD1. The format of the Treat-As-Withdraw attribute is the same as the format of the MP_UNREACH_NLRI as defined in Section 4 of .

Sending the Treat-As-Withdraw Attribute The Treat-As-Withdraw attribute may be sent in any BGP UPDATE message carrying the MP_REACH_NLRI attribute. It MUST NOT be sent in an UPDATE message not carrying the MP_REACH_NLRI attribute. To facilitate the determination of the NLRI field in an UPDATE message with a malformed attribute, the Treat-As-Withdraw SHALL be encoded as the very first path attribute in an UPDATE message, followed by the MP_REACH_NLRI attribute. (This represents an update to Section 5.1 , which mandated that the MP_REACH_NLRI come first.) The ordering of NLRIs within the Treat-As-Withdraw MUST be the same as their ordering within the corresponding MP_REACH_NLRI. If the AFI/SAFI specification allows for different NLRI encodings in the MP_UNREACH_NLRI, the sender MUST use the simplest encoding. The receiver MUST accept any valid encoding. For example, allows the use of either the MPLS label stack originally sent or the static 0x800000 value. The latter is simpler in that the size is smaller, fixed, and the number of labels to parse is minimized. The Treat-As-Withdraw attribute is generally useful as its encoding is simpler than the encoding of the MP_REACH_NLRI, hence it maximizes the chances of handling an error in the MP_REACH_NLRI attribute using the treat-as-withdraw approach. It is specifically useful for AFI/SAFI carrying non-key data in the NLRI such as , , and as these NLRI are longer and more complex, hence have a higher probability of error. In addition, in case of error, they have a lower probability of being able to parse the full list of NLRIs.

Receiving the Treat-As-Withdraw Attribute An UPDATE message with a malformed MP_REACH_NLRI attribute and a correctly formed Treat-As-Withdraw attribute SHALL be handled using the approach of "treat-as-withdraw". The UPDATE message SHALL be handled as if received with only the Treat-As-Withdraw attribute - all other attributes being ignored - and the Treat-As-Withdraw Attribute handled as an MP_UNREACH_NLRI attribute. In the case of an UPDATE message with a correctly formed MP_REACH_NLRI attribute, the Treat-As-Withdraw attribute SHOULD be parsed and its list of NLRI compared to the list of NLRI present in the MP_REACH_NLRI attribute. In case of difference, the Treat-As-Withdraw attribute SHALL be ignored. However, because this reveals an error in either the Treat-As-Withdraw attribute or the MP_REACH_NLRI attribute, a BGP speaker must provide debugging facilities to permit issues caused by a malformed attribute to be diagnosed. At a minimum, such facilities must include logging an error listing the NLRI involved and containing the entire malformed UPDATE message when such an attribute is detected. The malformed UPDATE message should be analyzed, and the root cause should be investigated.

Treat-As-Withdraw attribute Error Handling The Treat-As-Withdraw attribute has the same format as the MP_UNREACH_NLRI and hence has the same conditions under which it is considered malformed. As per , an UPDATE message with a malformed Treat-As-Withdraw attribute is handled using the approach of "attribute discard".

IANA Considerations IANA is requested to allocate a new optional, non-transitive attribute called "Treat-As-Withdraw" from the BGP Path Attributes registry of the Border Gateway Protocol (BGP) Parameters group.

Value	Code	Reference
TBD1	Treat-As-Withdraw	(this doc)

Security Considerations The Treat-As-Withdraw attribute does not change BGP security considerations. An attacker having the ability to send or modify a BGP Message has the ability to withdraw any NLRI, with or without the Treat-As-Withdraw attribute.

Acknowledgements

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS-TRACK] This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. Cisco Systems Cisco Systems This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR). This document describes the routing framework and BGP extensions to enable intent-aware routing using the BGP CAR solution. The solution defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an extensible NLRI model for both SAFIs that allow multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV based non-key fields for efficient encoding of different per-prefix information. This specification defines two NLRI types, Color-Aware Route NLRI and IP Prefix NLRI. It defines non-key TLV types for MPLS label stack, Label Index and SRv6 SIDs. This solution also defines a new Local Color Mapping (LCM) Extended Community. Juniper Networks, Inc. Juniper Networks, Inc. This document specifies a mechanism referred to as "Intent Driven Service Mapping". The mechanism uses BGP to express intent based association of overlay routes with underlay routes having specific Traffic Engineering (TE) characteristics satisfying a certain Service Level Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes"), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in TEAS Network Slices framework. Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages RFC 4364 ("BGP/MPLS IP Virtual Private Networks (VPNs)") procedures and follows RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") NLRI encoding is defined to enable each advertised underlay route to be identified by its class. This new address family is called "BGP Classful Transport", a.k.a., BGP CT.