NLRI Error handling

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 https://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 18 April 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

According to the base BGP specification [RFC4271], 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.¶

[RFC7606] 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 [RFC7606], 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.¶

[RFC4760] 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 [RFC8277], [I-D.ietf-idr-bgp-car], and [I-D.ietf-idr-bgp-ct] 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, [RFC8277] carries the Prefix in the key field and one label (stack) in the non-key field. As another example, [I-D.ietf-idr-bgp-car] 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.¶

2. 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 [RFC4760].¶

3. 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 [RFC7606], 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, [RFC3107] 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 [RFC8277], [I-D.ietf-idr-bgp-car], and [I-D.ietf-idr-bgp-ct] 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.¶

4. 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.¶

5. 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 Section 4, an UPDATE message with a malformed Treat-As-Withdraw attribute is handled using the approach of "attribute discard".¶

6. 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.¶

7. 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.¶

8. Acknowledgements

9. References

Authors' Addresses