< draft-merciaz-idr-bgp-bfd-strict-mode-01.txt   draft-merciaz-idr-bgp-bfd-strict-mode-02.txt >
IDR WorkGroup M. Zheng IDR WorkGroup M. Zheng
Internet-Draft A. Lindem Internet-Draft A. Lindem
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: October 5, 2019 April 3, 2019 Expires: January 8, 2020 J. Haas
Juniper Networks, Inc.
July 7, 2019
BGP BFD Strict-Mode BGP BFD Strict-Mode
draft-merciaz-idr-bgp-bfd-strict-mode-01 draft-merciaz-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 signal additional Bidirectional Forwarding Detection (BFD) speaker to negotiate additional Bidirectional Forwarding Detection
extensions using an optional parameter BFD capability. This BFD (BFD) extensions using a BGP capability. This BFD capability enables
capability enables a BGP speaker to prevent a BGP session from being a BGP speaker to prevent a BGP session from being established until a
established until a BFD session is established. It is referred to as BFD session is established. It is referred to as BGP BFD "strict-
BGP BFD "strict-mode". BGP BFD strict-mode will be supported when mode". BGP BFD strict-mode will be supported when both the local
both the local speaker and its remote peer are BFD strict-mode speaker and its remote peer are BFD strict-mode capable.
capable, Otherwise, a BGP speaker and its peer should not require a
BFD session for BGP session establishment.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 October 5, 2019. This Internet-Draft will expire on January 8, 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. BFD Capability . . . . . . . . . . . . . . . . . . . . . . . 3 3. BFD Capability . . . . . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 5. Manageability Considerations . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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 2, line 42 skipping to change at page 2, line 42
bidirectional forwarding detected by BFD result in session bidirectional forwarding detected by BFD result in session
termination. It is possible in some failure scenarios for the termination. It is possible in some failure scenarios for the
network to be in a state such that a BGP session may be established network to be in a state such that a BGP session may be established
but a BFD session cannot be established. In some other scenarios, it but a BFD session cannot be established. In some other scenarios, it
may be possible to establish a BGP session, but a degraded or poor- may be possible to establish a BGP session, but a degraded or poor-
quality link may result in the corresponding BFD session going up and quality link may result in the corresponding BFD session going up and
down frequently. down frequently.
To avoid situations which result in routing churn and to minimize the To avoid situations which result in routing churn and to minimize the
impact of network interruptions, it will be beneficial to disallow impact of network interruptions, it will be beneficial to disallow
BGP to establish a neighbor session until s BFD session is BGP to establish a session until BFD session is successfully
successfully established and has stabilized. We refer to this mode established and has stabilized. We refer to this mode of operation
of operation as BGP BFD "strict-mode". However, always using as BGP BFD "strict-mode". However, always using "strict-mode" would
"strict-mode" would preclude BGP operation in an environment where preclude BGP operation in an environment where not all routers
not all routers support BFD strict-mode or have BFD enabled. This support BFD strict-mode or have BFD enabled. This document defines
document defines BGP "strict-mode" operation as preventing BGP BGP "strict-mode" operation as preventing BGP session establishment
session establishment until both the local and remove speakers have a until both the local and remove speakers have a stable BFD session.
stable BFD session. The document also specifies the BGP protocol The document also specifies the BGP protocol extensions for BGP
extensions for BGP capability [RFC5492] for announcing BFD parameters capability [RFC5492] for announcing BFD parameters including a BGP
including a BGP speaker's support for "strict-mode", i.e., requiring speaker's support for "strict-mode", i.e., requiring a BFD session
a BFD session for BGP session establishment. for BGP session establishment.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. BFD Capability 3. BFD Capability
skipping to change at page 4, line 12 skipping to change at page 4, line 12
session establishment will be prevented until a BFD session is session establishment will be prevented until a BFD session is
established between the peering addresses. A BGP speaker with BFD established between the peering addresses. A BGP speaker with BFD
strict-mode enabled MUST advertise the BFD capability with "S" bit strict-mode enabled MUST advertise the BFD capability with "S" bit
set. set.
The remaining bits are reserved and SHOULD be set to zero by the The remaining bits are reserved and SHOULD be set to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
4. Operation 4. Operation
A BGP speaker that supports capabilities advertisement sends an OPEN
message to its BGP peer, the message MAY include an Optional
Parameter, called Capabilities. The parameter lists the capabilities
supported by the speaker. By following BGP capabilities
advertisement procedures defined in [RFC5492], BFD capability
advertisement for strict-mode is advertised to BGP peers.
If both BGP speakers advertise the BFD capability with the strict-
mode bit set, then the BGP state machine will be held in OpenConfirm
state [RFC4271] until a BFD session is established or the BGP session
is terminated for some other reason (e.g., the BGP Hold time expires.
A BGP speaker which supports capabilities advertisement and has BFD A BGP speaker which supports capabilities advertisement and has BFD
strict-mode enabled MUST include the BGP BFD capability with the "S" strict-mode enabled MUST include the BGP BFD capability with the "S"
Bit set in the BGP capabilities it advertises. Bit set in the BGP capabilities it advertises.
A BGP speaker which supports BFD capability advertisement, examines A BGP speaker which supports BFD capability, examines the list of
the list of capabilities present in the Capabilities BFD Parameter capabilities present in the Capabilities BFD Parameter that the
that the speaker receives from its peer. If both the local and speaker receives from its peer. If both the local and remote BGP
remote BGP speakers BFD strict-mode enabled, then the BGP session speakers have BFD strict-mode enabled, the BGP finite state machine
will be held in OpenConfirm state until a BFD session is established does not transition to the Established state from OpenSent or
between the two BGP speaker or the BGP session terminates for some OpenConfirm state [RFC4271] until the BFD session is in the Up state
other reason, e.g., the BGP hold timer expires. If either peer has (see below for AdminDown state). This means that a KEEPALIVE message
not advertised the BFD Capability with strict-mode enabled, then a is not sent nor is the KeepaliveTimer set.
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].
5. Backward Compatibility If the BFD session does not transition to the Up state, and the
HoldTimer has been negotiated to a non-zero value, the BGP FSM will
close the session appropriately. If the HoldTimer has been
negotiated to a zero value, the session should be closed after a time
of X. This time X is referred as "BGP BFD Hold time". The proposed
default BGP BFD Hold time value is 30 seconds. The BGP BFD Hold time
value is configurable.
The BFD capability will not introduce any backward compatibility will If BFD session is in the AdminDown state, then the BGP finite state
not result in any backward compatibility issues as long as the machine will proceed normally without input from BFD. This means
procedures in [RFC5492] and Section 4 are followed. As per that BFD session "AdminDown" state WILL NOT prevent the BGP state
[RFC5492], a BGP speaker which does not support the BFD capability transition to Established state from OpenConfirm.
will ignore the BFD capability. If a BGP speaker advertising the
capability receives the Unsupported Capability NOTIFICATION message Once the BFD session has transitioned to the Up state, the BGP FSM
and terminates the BGP session, the BGP speaker advertising the BFD may proceed to transition to the Established state from the OpenSent
capability SHOULD simply attempt to reestablish the BGP session with or OpenConfirm state appropriately. I.e. a KEEPALIVE message is
the BFD capability omitted. sent, and the KeepaliveTimer is started.
If either BGP peer has not advertised the BFD Capability with strict-
mode enabled, 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].
5. Manageability Considerations
Auto-configuration is possible for the enabling BGP BFD restrict-
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.)
6. Security Considerations 6. Security Considerations
This specification doesn't change the basic security model inherent The mechanism defined in this document interacts with the BGP finite
in [RFC4271]. However, it does introduce a new indirect attack state machine when so configured. The security considerations of BFD
vector for BGP since it is now dependent on BFD. thus become considerations for BGP-4 [RFC4271] so used. The use of
the BFD Authentication mechanism defined in [RFC5880] is thus
RECOMMENDED when used to protect BGP-4 [RFC4271].
7. IANA Considerations 7. IANA Considerations
This document defines a new BGP capability - BFD Capability. The This document defines a new BGP capability - BFD Capability. The
Capability Code for BFD Capability is TBD. Capability Code for BFD Capability is TBD.
IANA is requested to establish a "BGP BFD Capability Flags" registry IANA is requested to establish a "BGP BFD Capability Flags" registry
within the "Border Gateway Protocol (BGP) Parameters" grouping. The within the "Border Gateway Protocol (BGP) Parameters" grouping. The
Registration Procedure should be Standards Action, the initial values Registration Procedure should be Standards Action, the initial values
as follows: as follows:
skipping to change at page 5, line 31 skipping to change at page 5, line 43
+--------------+---------------+------------+---------------+ +--------------+---------------+------------+---------------+
| Bit Position | Name | Short Name | Reference | | Bit Position | Name | Short Name | Reference |
+--------------+---------------+------------+---------------+ +--------------+---------------+------------+---------------+
| 0 | Strict-Mode | S | this document | | 0 | Strict-Mode | S | this document |
| 1-7 | Unassigned | | this document | | 1-7 | Unassigned | | this document |
+--------------+---------------+------------+---------------+ +--------------+---------------+------------+---------------+
8. Acknowledgement 8. Acknowledgement
The authors would like to acknowledge the review and inputs from The authors would like to acknowledge the review and inputs from
Shyam Sethuram, Mohammed Mirza, and Bruno Decraene. Shyam Sethuram, Mohammed Mirza, Bruno Decraene, and Carlos Pignataro.
9. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, <https://www.rfc- DOI 10.17487/RFC4271, January 2006,
editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>. 2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC5882] Katz, D. and D. Ward, "Generic Application of [RFC5882] Katz, D. and D. Ward, "Generic Application of
Bidirectional Forwarding Detection (BFD)", RFC 5882, Bidirectional Forwarding Detection (BFD)", RFC 5882,
DOI 10.17487/RFC5882, June 2010, <https://www.rfc- DOI 10.17487/RFC5882, June 2010,
editor.org/info/rfc5882>. <https://www.rfc-editor.org/info/rfc5882>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses Authors' Addresses
Mercia Zheng Mercia Zheng
Cisco Systems Cisco Systems
821 Alder Drive, 821 Alder Drive
MILPITAS, CALIFORNIA 95035 MILPITAS, CALIFORNIA 95035
UNITED STATES UNITED STATES
Email: merciaz@cisco.com Email: merciaz@cisco.com
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
821 Alder Drive, 301 Midenhall Way
MILPITAS, CALIFORNIA 95035 GARY, NC 27513
UNITED STATES UNITED STATES
Email: acee@cisco.com Email: acee@cisco.com
Jeffrey Haas
Juniper Networks, Inc.
1133 Innovation Way
SUNNYVALE, CALIFORNIA 94089
UNITED STATES
Email: jhaas@juniper.net
 End of changes. 22 change blocks. 
72 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/