]> Orange

bruno.decraene@orange.com

HPE

jgs@bgp.nu

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 "NLRI_KEY_LIST 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_REACH_NLRI attribute prevents the parsing of its NLRIs. This document updates RFC 7606 by mandating that the NLRI_KEY_LIST 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 "NLRI_KEY_LIST attribute", to carry the NLRIs using the simple and existing format of MP_UNREACH_NLRI. Its most important use is for AFI/SAFI whose NLRI are considered to be at elevated risk of malformation. An example are AFI/SAFI that encode both a key field and a non-key field in the NLRIs of the MP_REACH_NLRI attribute, while encodes NLRI in a simpler way in the MP_UNREACH_NLRI attrbiute, e.g., with only the key field. For such AFI/SAFI, in case of an error in the MP_UNREACH_NLRI attribute preventing the identification of all NLRIs key, the parsing of the NLRI_KEY_LIST attribute is more likely allow the identification of all NLRIs key. This attribute is used to allow the treat-as-withdraw error-handling approach to be used when there is an error in the MP_REACH_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.

NLRI_KEY_LIST Capability To avoid the overhead of sending and receiving an attribute which is not understood by the BGP speaker receiving it, this document defines a new BGP Capability "NLRI_KEY_LIST", of type TBD2, and of length zero. A BGP speaker that supports the reception of the NLRI_KEY_LIST attribute () SHOULD advertise the NLRI_KEY_LIST Capability Advertisements. A BGP speaker SHOULD NOT send the NLRI_KEY_LIST attribute unless its peer has advertised the NLRI_KEY_LIST Capability. Note however that if the attribute is sent, it will cause no harm (an incapable implementation will disregard the attribute, per the base BGP specification). A potential reason to send the attribute to a peer that has not advertised support is to avoid fragmenting a peer group.

NLRI_KEY_LIST Attribute

NLRI_KEY_LIST Format The NLRI_KEY_LIST attribute is an optional, non-transitive BGP path attribute with type code TBD1. The format of the NLRI_KEY_LIST attribute is the same as the format of the MP_UNREACH_NLRI as defined in Section 4 of and the relevant specification for the AFI/SAFI in question.

Sending the NLRI_KEY_LIST attribute The NLRI_KEY_LIST attribute may be sent in a BGP UPDATE message carrying the MP_REACH_NLRI attribute with a least one reachable Network Layer Reachability Information (NLRI). It MUST NOT be sent:

• more than once in an UPDATE message;
• in an UPDATE message not carrying the MP_REACH_NLRI attribute;
• in an UPDATE message with an MP_REACH_NLRI attribute with no reachable Network Layer Reachability Information (NLRI).

To facilitate the parsing of the NLRI_KEY_LIST attribute in an UPDATE message with a malformed attribute, the NLRI_KEY_LIST 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 list and the ordering of NLRIs within the NLRI_KEY_LIST MUST be the same as the list and 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 NLRI_KEY_LIST 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. In particular the NLRI_KEY_LIST attribute does not carry the variable length "Network Address of Next Hop" field nor the "Length of Next Hop Network Address" which, if erroneous, trigger a BGP session reset as per . It is notably, although not exclusively, 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. It is less useful when the NLRI encoding is the same for MP_REACH_NLRI and MP_UNREACH_NLRI.

Receiving the NLRI_KEY_LIST attribute An UPDATE message with a malformed MP_REACH_NLRI attribute and a correctly formed NLRI_KEY_LIST attribute SHALL be handled using the approach of "treat-as-withdraw". The UPDATE message SHALL be handled as if received with only the NLRI_KEY_LIST attribute - all other attributes being ignored - and the NLRI_KEY_LIST attribute handled as an MP_UNREACH_NLRI attribute. In the case of an UPDATE message with a correctly formed MP_REACH_NLRI attribute, the NLRI_KEY_LIST 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 NLRI_KEY_LIST attribute SHALL be ignored. However, because this reveals an error in either the NLRI_KEY_LIST 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.

NLRI_KEY_LIST attribute Error Handling The NLRI_KEY_LIST 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 NLRI_KEY_LIST attribute is handled using the approach of "attribute discard".

Operational Considerations The choice of whether or not to send the NLRI_KEY_LIST attribute is up to the implementor and the operator. As is discussed elsewhere in this document, the attribute is considered more likely to be valuable for AFI/SAFI with more complex NLRI encodings, and less likely to be valuable in the case where the encodings used for the MP_REACH_NLRI and MP_UNREACH_NLRI are the same. Drawbacks of sending the attribute include space overhead in the UPDATE message, as well as time overhead to form the attribute on the sender side and to validate it on the receiver side. The primary advantage of sending the attribute is avoidance of session reset with concomitant service disruption, but one may also observe the potential to detect non-fatal errors which would otherwise be invisible, when the NLRI_KEY_LIST attribute is compared to the MP_REACH_NLRI attribute. The latter might motivate an operator to configure support even for less complex AFI/SAFI. An implementation SHOULD provide a configuration option allowing the operator to send, or not send, the attribute with any AFI/SAFI. The default may differ for different AFI/SAFI; this specification does not, in any case, mandate a default.

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

Value	Code	Reference
TBD1	NLRI_KEY_LIST	(this doc)

IANA is requested to allocate a new capability called "NLRI_KEY_LIST" from the Capability Codes registry.

Value	Description	Reference
TBD2	NLRI_KEY_LIST	(this doc)

Security Considerations The NLRI_KEY_LIST 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 NLRI_KEY_LIST attribute.

Acknowledgements The authors of this specification thank Jeffrey Haas, Robert Raszuk and Donatas Abraitis for their review and comments.

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] This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. [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. 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 Network Layer Reachability Information (NLRI) model for both SAFIs that allows 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 the MPLS label stack, SR-MPLS label index, and Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). This solution also defines a new Local Color Mapping (LCM) Extended Community. 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" or "TCs"), 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 the TEAS Network Slices framework (RFC 9543). 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 the procedures described in RFC 4364 ("BGP/MPLS IP Virtual Private Networks (VPNs)") and follows the NLRI encoding described in RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") is defined to enable each advertised underlay route to be identified by its class. This new address family is called "BGP Classful Transport" (or "BGP CT").