



Internet Engineering Task Force                              B. Decraene
Internet-Draft                                                    Orange
Updates: 7606 (if approved)                                J. G. Scudder
Intended status: Standards Track                                     HPE
Expires: 18 April 2026                                   15 October 2025


                          NLRI Error handling
               draft-decraene-idr-nlri-error-handling-00

Abstract

   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.

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.



Decraene & Scudder        Expires 18 April 2026                 [Page 1]

Internet-Draft             NLRI Error handling              October 2025


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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Treat-As-Withdraw Attribute . . . . . . . . . . . . . . . . .   3
   3.  Sending the Treat-As-Withdraw Attribute . . . . . . . . . . .   4
   4.  Receiving the Treat-As-Withdraw Attribute . . . . . . . . . .   4
   5.  Treat-As-Withdraw attribute Error Handling  . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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.













Decraene & Scudder        Expires 18 April 2026                 [Page 2]

Internet-Draft             NLRI Error handling              October 2025


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

1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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



Decraene & Scudder        Expires 18 April 2026                 [Page 3]

Internet-Draft             NLRI Error handling              October 2025


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



Decraene & Scudder        Expires 18 April 2026                 [Page 4]

Internet-Draft             NLRI Error handling              October 2025


   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.

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

                                 Table 1

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

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.







Decraene & Scudder        Expires 18 April 2026                 [Page 5]

Internet-Draft             NLRI Error handling              October 2025


   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/rfc/rfc4271>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/rfc/rfc4760>.

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <https://www.rfc-editor.org/rfc/rfc7606>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

9.2.  Informative References

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
              <https://www.rfc-editor.org/rfc/rfc3107>.

   [RFC8277]  Rosen, E., "Using BGP to Bind MPLS Labels to Address
              Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
              <https://www.rfc-editor.org/rfc/rfc8277>.

   [I-D.ietf-idr-bgp-car]
              Rao, D. and S. Agrawal, "BGP Color-Aware Routing (CAR)",
              Work in Progress, Internet-Draft, draft-ietf-idr-bgp-car-
              16, 20 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
              car-16>.

   [I-D.ietf-idr-bgp-ct]
              Vairavakkalai, K. and N. Venkataraman, "BGP Classful
              Transport Planes", Work in Progress, Internet-Draft,
              draft-ietf-idr-bgp-ct-39, 28 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
              ct-39>.

Authors' Addresses

   Bruno Decraene
   Orange
   Email: bruno.decraene@orange.com



Decraene & Scudder        Expires 18 April 2026                 [Page 6]

Internet-Draft             NLRI Error handling              October 2025


   John G. Scudder
   HPE
   Email: jgs@juniper.net
















































Decraene & Scudder        Expires 18 April 2026                 [Page 7]
