--- 1/draft-ietf-idr-bgp-bfd-strict-mode-01.txt	2019-11-04 13:18:18.613665303 -0800
+++ 2/draft-ietf-idr-bgp-bfd-strict-mode-02.txt	2019-11-04 13:18:18.629665709 -0800
@@ -1,23 +1,23 @@
 
 IDR Workgroup                                                   M. Zheng
 Internet-Draft                                    Individual Contributor
 Intended status: Standards Track                               A. Lindem
-Expires: May 5, 2020                                       Cisco Systems
+Expires: May 7, 2020                                       Cisco Systems
                                                                  J. Haas
                                                   Juniper Networks, Inc.
                                                                    A. Fu
                                                           Bloomberg L.P.
-                                                        November 2, 2019
+                                                        November 4, 2019
 
                           BGP BFD Strict-Mode
-                 draft-ietf-idr-bgp-bfd-strict-mode-01
+                 draft-ietf-idr-bgp-bfd-strict-mode-02
 
 Abstract
 
    This document specifies extensions to RFC4271 BGP-4 that enable a BGP
    speaker to negotiate additional Bidirectional Forwarding Detection
    (BFD) extensions using a BGP capability.  This BFD capability enables
    a BGP speaker to prevent a BGP session from being established until a
    BFD session is established.  It is referred to as BGP BFD "strict-
    mode".  BGP BFD strict-mode will be supported when both the local
    speaker and its remote peer are BFD strict-mode capable.
@@ -30,21 +30,21 @@
    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 May 5, 2020.
+   This Internet-Draft will expire on May 7, 2020.
 
 Copyright Notice
 
    Copyright (c) 2019 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
@@ -57,21 +57,21 @@
 Table of Contents
 
    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
    2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
    3.  BFD Strict-Mode Capability  . . . . . . . . . . . . . . . . .   3
    4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   3
    5.  Manageability Considerations  . . . . . . . . . . . . . . . .   4
    6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
    8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   4
-   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
+   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5
 
 1.  Introduction
 
    Bidirectional Forwarding Detection BFD [RFC5882] enables routers to
    monitor data plane connectivity and to detect faults in the
    bidirectional forwarding path between them.  This capability is
    leveraged by routing protocols such as BGP [RFC4271] to rapidly react
    to topology changes in the face of path failures.
 
@@ -112,22 +112,22 @@
 
    The BGP Strict-Mode Capability [RFC5492] will allow a BGP speaker's
    to advertise this capability.  The capability is defined as follows:
 
    Capability code: TBD
 
    Capability length: 0 octets
 
 4.  Operation
 
-   A BGP speaker which supports capabilities advertisement MUST include
-   the BFD strict-mode capability.
+   A BGP speaker which supports capabilities advertisement and has BFD
+   strict-mode enabled MUST include the BFD strict-mode capability.
 
    A BGP speaker which supports the BFD Strict-Mode capability, examines
    the list of capabilities present in the capabilities that the speaker
    receives from its peer.  If both the local and remote BGP speakers
    include the BFD strict-mode capability, the BGP finite state machine
    does not transition to the Established state from OpenSent or
    OpenConfirm state [RFC4271] until the BFD session is in the Up state
    (see below for AdminDown state).  This means that a KEEPALIVE message
    is not sent nor is the KeepaliveTimer set.
 
@@ -147,20 +147,24 @@
    Once the BFD session has transitioned to the Up state, the BGP FSM
    may proceed to transition to the Established state from the OpenSent
    or OpenConfirm state appropriately.  I.e. a KEEPALIVE message is
    sent, and the KeepaliveTimer is started.
 
    If either BGP peer has not advertised the BFD Strict-Mode Capability,
    then a BFD session WILL NOT be required for the BGP session to reach
    Established state.  This does not preclude usage of BFD after BGP
    session establishment [RFC5882].
 
+   If BFD is disabled for a BGP peer and the BGP session state is being
+   held in OpenSent or OpenConfirm state, then the BGP will close
+   session, and start a new TCP connect.
+
 5.  Manageability Considerations
 
    Auto-configuration is possible for the enabling BGP BFD Strict-Mode.
    However, the configuration automation is out of the scope of this
    document.
 
    A BGP NOTIFICATION message Subcode indicating BFD Hold timer
    expiration may be required for network management.  (To be discussed
    in the next revision of this document.)