--- 1/draft-ietf-lsr-ospf-bfd-strict-mode-01.txt 2020-12-30 22:13:11.633075487 -0800 +++ 2/draft-ietf-lsr-ospf-bfd-strict-mode-02.txt 2020-12-30 22:13:11.657076094 -0800 @@ -1,22 +1,22 @@ Link State Routing K. Talaulikar Internet-Draft P. Psenak Intended status: Standards Track Cisco Systems, Inc. -Expires: January 1, 2021 A. Fu +Expires: July 3, 2021 A. Fu Bloomberg M. Rajesh Juniper Networks - June 30, 2020 + December 30, 2020 OSPF Strict-Mode for BFD - draft-ietf-lsr-ospf-bfd-strict-mode-01 + draft-ietf-lsr-ospf-bfd-strict-mode-02 Abstract This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional Forwarding Detection (BFD) session prior to adjacency formation. Link-Local Signaling (LLS) is used to advertise this requirement of "strict- mode" of BFD session establishment for OSPF adjacency. If both OSPF neighbors advertise the "strict-mode" of BFD, adjacency formation will be blocked until a BFD session has been successfully @@ -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 January 1, 2021. + This Internet-Draft will expire on July 3, 2021. Copyright Notice Copyright (c) 2020 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 @@ -52,25 +52,25 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. LLS B-bit Flag . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Local Interface IPv4 Address TLV . . . . . . . . . . . . . . 3 + 3. Local Interface IPv4 Address TLV . . . . . . . . . . . . . . 4 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. OSPFv3 IPv4 Address-Family Specifics . . . . . . . . . . 6 4.2. Graceful Restart Considerations . . . . . . . . . . . . . 6 - 5. Operations & Management Considerations . . . . . . . . . . . 6 + 5. Operations & Management Considerations . . . . . . . . . . . 7 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction @@ -87,21 +87,24 @@ described in [RFC5882]. When BFD monitoring is enabled for OSPF adjacencies, the BFD session is bootstrapped based on the neighbor address information discovered by the exchange of OSPF hello packets. Faults in the bidirectional forwarding detected via BFD then result in the OSPF adjacency being brought down. Note that it is possible in some failure scenarios for the network to be in a state such that an OSPF adjacency can be established but a BFD session cannot be established and maintained. In certain other scenarios, a degraded or poor quality link may result in OSPF adjacency formation to succeed only to result in BFD session establishment not being - successful or flapping of the BFD session. + successful or flapping of the BFD session. In this case, traffic + that gets forwarded over such a link may experience packet drops + while the failure of BFD session establishment would not enable fast + routing convergence if the link were to go down or flap. To avoid the routing churn associated with these scenarios, it would be beneficial to not allow OSPF to establish an adjacency until a BFD session is successfully established and has stabilized. However, this would preclude the OSPF operation in an environment in which not all OSPF routers support BFD and are enabled for BFD on the link. A solution is to block OSPF adjacency establishment until a BFD session is established as long as both neighbors advertise such a requirement. Such a mode of OSPF BFD usage is referred to as "strict-mode". @@ -145,21 +148,21 @@ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: - Type: TBD, suggested value 21 + Type: 21 Length: 4 octet Local Interface IPv4 Address: The primary IPv4 address of the local interface. 4. Procedures A router supporting BFD strict-mode advertises this capability through its hello messages as described in Section 2. When a router @@ -189,21 +191,21 @@ appear in the neighbor's Hello packet). A BFD session establishment to the neighbor is requested, if not already done (e.g. in the event of transition from 2-way state). Neighbors in Init state or higher will be listed in the Hello packets associated with the interface if they either have a corresponding BFD session established or have not advertised "strict-mode" BFD in the Hello packet LLS Extended Options and Flags. Whenever the neighbor state transitions to Down state, the removal of the BFD session associated with that neighbor SHOULD be requested by - OSPF and subsequent BFD session establishement SHOULD similarly be + OSPF and subsequent BFD session establishment SHOULD similarly be requested by OSPF upon transitioning into Init state. This may result in the deletion and creation of the BFD session respectively when OSPF is the only client interested in the BFD session to the neighbor address. An implementation MUST NOT wait for BFD session establishment in Init state unless BFD strict-mode is enabled on the router and the specific neighbor indicates BFD strict-mode capability via its Hello LLS options. When BFD is enabled, but the strict-mode of operation has not be signaled by both neighbors, then an implementation SHOULD @@ -244,54 +246,54 @@ OSPFv3 IPv4 AF, it is required that BFD is used to monitor and verify the IPv4 data plane connectivity between the routers on the link and, hence, the BFD session is setup using IPv4 neighbor addresses. The IPv4 neighbor address on the interface is learnt only later in the adjacency formation process when the neighbor's Link-LSA is received. This results in the setup of the BFD session either after the adjacency is established or later in the adjacency formation sequence. To enable BFD operation in strict-mode, it is necessary for an OSPF - router to learn it's neighbor's IPv4 link address during the Init + router to learned it's neighbor's IPv4 link address during the Init state of adjacency formation (ideally when it receives the first hello). The use of the Local Interface IPv4 Address TLV (as defined in Section 3) in the LLS block of the OSPFv3 Hello messages for IPv4 AF instances makes this possible. Implementations that support strict-mode of BFD operation for OSPFv3 IPv4 AF instances MUST include the Local Interface IPv4 Address TLV in the LLS block of their hello messages whenever the B-bit is also set in the LLS Options and Flags field. A receiver MUST ignore the B-bit (i.e., not operate in BFD strict mode) when the Local Interface IPv4 Address TLV is not present in OSPFv3 Hello message for IPv4 AF OSPFv3 instances. 4.2. Graceful Restart Considerations An implementation needs to handle scenarios where both graceful restart (GR) and the strict-mode of BFD operation are deployed together. The GR aspects discussed in [RFC5882] also apply with strict-mode of BFD operation. Additionally, in strict-mode of BFD operation, since the OSPF adjacency formation is delayed until the - BFD session establishment, the resultant delay in adajcency formation + BFD session establishment, the resultant delay in adjacency formation may affect or break the GR-based recovery. In such cases, it is RECOMMENDED that the GR timers are set such that they provide sufficient time to allow for normal BFD session establishment delays. 5. Operations & Management Considerations An implementation SHOULD report the BFD session status along with the OSPF Init adjacency state when operating in BFD strict-mode and perform logging operations on state transitions to include the BFD events. This allows an operator to detect scenarios where an OSPF adjacency may be stuck waiting for BFD session establishment. In network deployments with noisy links or those with packet loss, - BFD sessions may flap frequently. In such scenarions, OSPF strict- + BFD sessions may flap frequently. In such scenarios, OSPF strict- mode for BFD may be deployed in conjunction with a BFD dampening or hold-down mechanism to help avoid frequent adjacency flaps that cause routing churn. 6. Backward Compatibility An implementation MUST support OSPF adjacency formation and operations with a neighbor router that does not advertise the BFD strict-mode capability - both when that neighbor router does not support BFD and when it does support BFD but not in the strict-mode @@ -315,26 +317,26 @@ with such OSPF routers. As a result, the behavior would be the same as before this specification. Therefore, there are no backward compatibility issues or implementations considerations beyond what is specified herein. 7. IANA Considerations This specification updates Link Local Signaling TLV Identifiers registry. - Following values are requested for allocation: + Following values have been assigned via early allocation: o B-bit from "LLS Type 1 Extended Options and Flags" registry at bit position 0x00000010. - o TBD (Suggested value 21) - Local Interface IPv4 Address TLV + o Type 21 - Local Interface IPv4 Address TLV 8. Security Considerations The security considerations for "OSPF Link-Local Signaling" [RFC5613] also apply to the extension described in this document. Inappropriate use of the B-bit in the LLS block of an OSPF hello message could prevent an OSPF adjacency from forming or lead to failure to detect bidirectional forwarding failures. If authentication is being used in the OSPF routing domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV