| < draft-ietf-idr-bgp-bfd-strict-mode-01.txt | draft-ietf-idr-bgp-bfd-strict-mode-02.txt > | |||
|---|---|---|---|---|
| IDR Workgroup M. Zheng | IDR Workgroup M. Zheng | |||
| Internet-Draft Individual Contributor | Internet-Draft Individual Contributor | |||
| Intended status: Standards Track A. Lindem | Intended status: Standards Track A. Lindem | |||
| Expires: May 5, 2020 Cisco Systems | Expires: May 7, 2020 Cisco Systems | |||
| J. Haas | J. Haas | |||
| Juniper Networks, Inc. | Juniper Networks, Inc. | |||
| A. Fu | A. Fu | |||
| Bloomberg L.P. | Bloomberg L.P. | |||
| November 2, 2019 | November 4, 2019 | |||
| BGP BFD Strict-Mode | BGP BFD Strict-Mode | |||
| draft-ietf-idr-bgp-bfd-strict-mode-01 | draft-ietf-idr-bgp-bfd-strict-mode-02 | |||
| Abstract | Abstract | |||
| This document specifies extensions to RFC4271 BGP-4 that enable a BGP | This document specifies extensions to RFC4271 BGP-4 that enable a BGP | |||
| speaker to negotiate additional Bidirectional Forwarding Detection | speaker to negotiate additional Bidirectional Forwarding Detection | |||
| (BFD) extensions using a BGP capability. This BFD capability enables | (BFD) extensions using a BGP capability. This BFD capability enables | |||
| a BGP speaker to prevent a BGP session from being established until a | 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- | BFD session is established. It is referred to as BGP BFD "strict- | |||
| mode". BGP BFD strict-mode will be supported when both the local | mode". BGP BFD strict-mode will be supported when both the local | |||
| speaker and its remote peer are BFD strict-mode capable. | speaker and its remote peer are BFD strict-mode capable. | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | 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 Notice | |||
| Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 22 ¶ | skipping to change at page 2, line 22 ¶ | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 | 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. BFD Strict-Mode Capability . . . . . . . . . . . . . . . . . 3 | 3. BFD Strict-Mode Capability . . . . . . . . . . . . . . . . . 3 | |||
| 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 5. Manageability Considerations . . . . . . . . . . . . . . . . 4 | 5. Manageability Considerations . . . . . . . . . . . . . . . . 4 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 | 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 | 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 1. Introduction | 1. Introduction | |||
| Bidirectional Forwarding Detection BFD [RFC5882] enables routers to | Bidirectional Forwarding Detection BFD [RFC5882] enables routers to | |||
| monitor data plane connectivity and to detect faults in the | monitor data plane connectivity and to detect faults in the | |||
| bidirectional forwarding path between them. This capability is | bidirectional forwarding path between them. This capability is | |||
| leveraged by routing protocols such as BGP [RFC4271] to rapidly react | leveraged by routing protocols such as BGP [RFC4271] to rapidly react | |||
| to topology changes in the face of path failures. | to topology changes in the face of path failures. | |||
| skipping to change at page 3, line 29 ¶ | skipping to change at page 3, line 29 ¶ | |||
| The BGP Strict-Mode Capability [RFC5492] will allow a BGP speaker's | The BGP Strict-Mode Capability [RFC5492] will allow a BGP speaker's | |||
| to advertise this capability. The capability is defined as follows: | to advertise this capability. The capability is defined as follows: | |||
| Capability code: TBD | Capability code: TBD | |||
| Capability length: 0 octets | Capability length: 0 octets | |||
| 4. Operation | 4. Operation | |||
| A BGP speaker which supports capabilities advertisement MUST include | A BGP speaker which supports capabilities advertisement and has BFD | |||
| the BFD strict-mode capability. | strict-mode enabled MUST include the BFD strict-mode capability. | |||
| A BGP speaker which supports the BFD Strict-Mode capability, examines | A BGP speaker which supports the BFD Strict-Mode capability, examines | |||
| the list of capabilities present in the capabilities that the speaker | the list of capabilities present in the capabilities that the speaker | |||
| receives from its peer. If both the local and remote BGP speakers | receives from its peer. If both the local and remote BGP speakers | |||
| include the BFD strict-mode capability, the BGP finite state machine | include the BFD strict-mode capability, the BGP finite state machine | |||
| does not transition to the Established state from OpenSent or | does not transition to the Established state from OpenSent or | |||
| OpenConfirm state [RFC4271] until the BFD session is in the Up state | OpenConfirm state [RFC4271] until the BFD session is in the Up state | |||
| (see below for AdminDown state). This means that a KEEPALIVE message | (see below for AdminDown state). This means that a KEEPALIVE message | |||
| is not sent nor is the KeepaliveTimer set. | is not sent nor is the KeepaliveTimer set. | |||
| skipping to change at page 4, line 15 ¶ | skipping to change at page 4, line 15 ¶ | |||
| Once the BFD session has transitioned to the Up state, the BGP FSM | Once the BFD session has transitioned to the Up state, the BGP FSM | |||
| may proceed to transition to the Established state from the OpenSent | may proceed to transition to the Established state from the OpenSent | |||
| or OpenConfirm state appropriately. I.e. a KEEPALIVE message is | or OpenConfirm state appropriately. I.e. a KEEPALIVE message is | |||
| sent, and the KeepaliveTimer is started. | sent, and the KeepaliveTimer is started. | |||
| If either BGP peer has not advertised the BFD Strict-Mode Capability, | 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 | 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 | Established state. This does not preclude usage of BFD after BGP | |||
| session establishment [RFC5882]. | 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 | 5. Manageability Considerations | |||
| Auto-configuration is possible for the enabling BGP BFD Strict-Mode. | Auto-configuration is possible for the enabling BGP BFD Strict-Mode. | |||
| However, the configuration automation is out of the scope of this | However, the configuration automation is out of the scope of this | |||
| document. | document. | |||
| A BGP NOTIFICATION message Subcode indicating BFD Hold timer | A BGP NOTIFICATION message Subcode indicating BFD Hold timer | |||
| expiration may be required for network management. (To be discussed | expiration may be required for network management. (To be discussed | |||
| in the next revision of this document.) | in the next revision of this document.) | |||
| End of changes. 7 change blocks. | ||||
| 7 lines changed or deleted | 11 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||