<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-zwg-rtgwg-enhanced-bgp-resilience-00"
     ipr="trust200902">
  <front>
    <title abbrev="Enhanced BGP Resilience">Enhanced BGP Resilience</title>

    <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhuangshunwan@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Haibo Wang" initials="H." surname="Wang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>rainsword.wang@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="24" month="November" year="2025"/>

    <abstract>
      <t>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. RFC7606
      revises the error handling procedures for a number of existing
      attributes. The use of the "treat-as-withdraw" and "attribute discard"
      approaches significantly reduces the likelihood of BGP sessions being
      reset when receiving malformed BGP update messages, thereby greatly
      enhancing network stability. However, in practical applications, there
      are still numerous instances where BGP session oscillations occur due to
      the receipt of malformed BGP update messages, unrecognized attribute
      fields, or routing rules generated by a certain BGP AFI/SAFI that affect
      the forwarding of BGP messages.</t>

      <t>This document introduces some approaches to enhance the stability of
      BGP sessions.</t>

      <t/>
    </abstract>

    <note title="Requirements Language">
      <t>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
      <xref target="RFC2119">RFC 2119</xref> <xref target="RFC8174"/> when,
      and only when, they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>As the internet carries an increasing number of services, its
      stability has become more and more important. The BGP protocol plays a
      crucial role in the internet, enabling different ISPs and enterprises to
      provide symmetrical and reliable connection services, ensuring that
      information and data on the internet can be transmitted and exchanged
      quickly and securely. The oscillation of BGP protocol sessions can have
      a significant negative impact on the internet. The method introduced in
      RFC7606 promotes the stability of BGP protocol sessions. However, in
      practical applications, there are still numerous instances where BGP
      session oscillations occur due to the receipt of malformed BGP update
      messages, unrecognized attribute fields, or routing rules generated by a
      certain BGP AFI/SAFI that affect the forwarding of BGP messages.</t>

      <t>This document introduces some approaches to enhance the stability of
      BGP sessions.</t>

      <t/>
    </section>

    <section title="Definitions and Acronyms">
      <t><list style="symbols">
          <t>AFI: Address Family Identifiers</t>

          <t>FlowSpec: Flow Specification</t>

          <t>ISP: Internet Service Provider</t>

          <t>SAFI: Subsequent Address Family Identifiers</t>
        </list></t>
    </section>

    <section title="BGP Protection Mode">
      <t>As shown in the figure below, the process of BGP protection mode
      operation is described.</t>

      <t><figure>
          <artwork align="left"><![CDATA[  Router2                       Router1
     ~                             ~
     |--------BGP Flapping---------| 
     |                             |
     |                             * Router1 detectes multiple 
     |                             |  oscillations in the BGP session
     |                             |  and initiates BGP protection
     |                             |  mode.
     |                             |
     |<-------BGP Open Msg.--------* The BGP Open message sends by 
     |                             |  Router1 contains only the 
     |                             |  capability parameter sets defined 
     |                             |  by the protection mode.
     |                             |  
     *--------BGP Open Msg.------->|  
     |                             * When receiving a BGP Open message
     |                             |  from Router2, only the predefined 
     |                             |  capability sets are accepted, while
     |                             |  the rest are ignored.
     |-------Session Established---|
     |                             |
     |<-------BGP Update Msg.------* Router1 sends Update messages in  
     |                             |  protected mode.
     |                             |
     *--------BGP Update Msg.----->| 
     |                             * Router1 processes the received Update
     |                             |  message in protection mode.       
     ~                             ~


     Figure 1: Schematic Diagram of BGP Protection Mode Operation

]]></artwork>
        </figure>The processing procedure is as follows:</t>

      <t>1) Router1 detectes multiple oscillations in the BGP session and
      initiates BGP protection mode.</t>

      <t>2) The BGP Open message sent by Router1 contains only the capability
      parameter sets defined by the protection mode.</t>

      <t>For example:</t>

      <t>Before implementing this solution: Send IPv4 unicast address family,
      IPv4 Flowspec address family, Route Refresh capability, etc. In some
      erroneous operations, the rules published by the Flowspec address family
      can filter out protocol messages in the BGP session, leading to a
      prolonged absence of protocol message exchanges and ultimately causing
      the BGP session to be interrupted.</t>

      <t>After implementing this solution: Only send IPv4 unicast address
      family and Route Refresh capability, and no longer send IPv4 Flowspec
      address family and other capability parameters that may cause
      oscillation.</t>

      <t>3) When receiving a BGP Open message from Router2, only the
      predefined capability sets are accepted, while the rest are ignored.
      After this operational step, Router1 does not have the capability to
      filter protocol packets for the new session. This eliminates the issue
      of repeated BGP session flaps caused by problematic Flowspec routes.</t>

      <t>4) After the BGP session is established, when Router1 sends a BGP
      Update message to Router2, the BGP Update message contains only the set
      of attributes customized for protection mode.</t>

      <t>5) When Router1 receives a BGP Update message from Router2, it only
      accepts the set of attributes in the BGP update that are configured for
      protection mode, while ignoring other BGP path attributes.</t>

      <t/>
    </section>

    <section title="BGP Diagnostic Mode">
      <t>As shown in the figure below, the process of BGP Diagnostic mode
      operation is described.</t>

      <t><figure>
          <artwork align="left"><![CDATA[  Router2                       Router1
     ~                             ~
     |--------BGP Flapping---------| 
     |                             |
     |                             * Router1 detectes multiple 
     |                             |  oscillations in the BGP session
     |                             |  and initiates BGP Diagnostic
     |                             |  mode.
     |                             |
     ~                             ~


     Figure 2: Schematic Diagram of BGP Diagnostic Mode Operation

]]></artwork>
        </figure></t>

      <t>After the BGP session has flapped multiple times (determine a
      threshold, for example, 5 times), the router implementing this solution
      enters diagnostic mode the next time the BGP session starts:</t>

      <t>1) Upon entering diagnostic mode, the router allocates additional
      storage resources to the BGP module and optionally activates some
      diagnostic modules that are typically disabled in normal mode. These
      diagnostic modules may usually impact the operational performance of
      BGP.</t>

      <t>2) The router records the BGP messages received and sent to the peer
      and stores them.</t>

      <t>3) The diagnostic module on the router performs a diagnostic analysis
      of the legality of the BGP messages.</t>

      <t>4) If the diagnostic module identifies some issues, when the session
      restarts or it actively restarts the session: at this point, it excludes
      the information causing the fault from the messages sent and ignores the
      information causing the fault when processing the information received
      from the peer.</t>

      <t>5) If the session continues to flap after starting diagnostic mode
      (either because the diagnostic module did not promptly identify the
      issue or because there is no diagnostic module), the router initiates
      the protection mode; the subsequent process is the same as in section
      3.</t>

      <t/>
    </section>

    <section title="Error Handling">
      <t>TBD</t>

      <t/>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>No IANA actions are required for this document.</t>

      <t/>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document does not change the security properties of BGP.</t>

      <t/>
    </section>

    <section title="Contributors ">
      <t>TBD</t>

      <t/>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to acknowledge the review and inputs from ...
      (TBD)</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.4271'?>

      <?rfc include='reference.RFC.4360'?>

      <?rfc include='reference.RFC.4760'?>

      <?rfc include='reference.RFC.5701'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8660'?>

      <?rfc include='reference.RFC.8669'?>

      <?rfc include='reference.RFC.8955'?>

      <?rfc include='reference.RFC.8956'?>

      <?rfc include='reference.RFC.9012'?>

      <?rfc include='reference.RFC.9252'?>

      <?rfc include='reference.RFC.9256'?>

      <?rfc include='reference.I-D.ietf-idr-sr-policy-safi'?>

      <?rfc include='reference.I-D.ietf-idr-fsv2-ip-basic'?>

      <?rfc include='reference.I-D.ietf-idr-flowspec-redirect-ip'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.8754'?>

      <?rfc include='reference.I-D.ietf-pce-segment-routing-policy-cp'?>
    </references>
  </back>
</rfc>
