rfc9355xml2.original.xml   rfc9355.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc compact="yes"?> std"
<?rfc subcompact="no"?> consensus="true" docName="draft-ietf-lsr-ospf-bfd-strict-mode-10" number="9355"
<rfc category="std" docName="draft-ietf-lsr-ospf-bfd-strict-mode-10" ipr="trust200902" updates="2328" obsoletes="" xml:lang="en" tocInclude="true" to
ipr="trust200902" updates="2328"> cDepth="3" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.15.0 -->
<front> <front>
<title abbrev="OSPF BFD Strict-Mode">OSPF BFD Strict-Mode</title>
<author fullname="Ketan Talaulikar" initials="K." role="editor" <title abbrev="OSPF BFD Strict-Mode">OSPF Bidirectional Forwarding
surname="Talaulikar"> Detection (BFD) Strict-Mode</title>
<seriesInfo name="RFC" value="9355"/>
<author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Tal
aulikar">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<code/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Peter Psenak" initials="P." surname="Psenak"> <author fullname="Peter Psenak" initials="P." surname="Psenak">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Apollo Business Center</street> <extaddr>Apollo Business Center</extaddr>
<street>Mlynske nivy 43</street> <street>Mlynske nivy 43</street>
<city>Bratislava</city> <city>Bratislava</city>
<code>821 09</code> <code>821 09</code>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<email>ppsenak@cisco.com</email> <email>ppsenak@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Albert Fu" initials="A." surname="Fu"> <author fullname="Albert Fu" initials="A." surname="Fu">
<organization>Bloomberg</organization> <organization>Bloomberg</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<street/>
<city/>
<code/>
<country>USA</country>
</postal> </postal>
<email>afu14@bloomberg.net</email> <email>afu14@bloomberg.net</email>
</address> </address>
</author> </author>
<author fullname="Rajesh M" initials="M." surname="Rajesh"> <author fullname="Rajesh M" initials="M." surname="Rajesh">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street/>
<street/>
<city/>
<code/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>mrajesh@juniper.net</email> <email>mrajesh@juniper.net</email>
</address> </address>
</author> </author>
<date year="2023" month="February"/>
<date year=""/> <area>rtg</area>
<workgroup>lsr</workgroup>
<area>Routing</area>
<workgroup>Link State Routing</workgroup>
<keyword>IGP</keyword> <keyword>IGP</keyword>
<keyword>OSPF</keyword> <keyword>OSPF</keyword>
<abstract> <abstract>
<t>This document specifies the extensions to OSPF that enable an OSPF <t>This document specifies the extensions to OSPF that enable an OSPF
router to signal the requirement for a Bidirectional Forwarding router to signal the requirement for a Bidirectional Forwarding
Detection (BFD) session prior to adjacency formation. Link-Local Detection (BFD) session prior to adjacency formation. Link-Local
Signaling (LLS) is used to advertise the requirement for strict-mode BFD Signaling (LLS) is used to advertise the requirement for strict-mode BFD
session establishment for an OSPF adjacency. If both OSPF neighbors session establishment for an OSPF adjacency. If both OSPF neighbors
advertise BFD strict-mode, adjacency formation will be blocked until a advertise BFD strict-mode, adjacency formation will be blocked until a
BFD session has been successfully established.</t> BFD session has been successfully established.</t>
<t>This document updates RFC 2328 by augmenting the OSPF neighbor state
<t>This document updates RFC2328 by augmenting the OSPF neighbor state
machine with a check for BFD session up before progression from Init to machine with a check for BFD session up before progression from Init to
Two-Way state when operating in OSPF BFD strict-mode.</t> 2-Way state when operating in OSPF BFD strict-mode.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<t>Bidirectional Forwarding Detection (BFD) <xref target="RFC5880"/> <name>Introduction</name>
enables routers to monitor data-plane connectivity and to detect faults <t>Bidirectional Forwarding Detection (BFD) <xref target="RFC5880" format=
in the bidirectional path between them. BFD is leveraged by routing "default"/>
protocols like OSPFv2 <xref target="RFC2328"/> and OSPFv3 <xref enables routers to monitor data plane connectivity and to detect faults
target="RFC5340"/> to detect connectivity failures for established in the bidirectional path between them.
adjacencies faster than the OSPF hello dead timer detection and trigger BFD is leveraged by routing
protocols like OSPFv2 <xref target="RFC2328" format="default"/> and OSPFv3
<xref target="RFC5340" format="default"/> to detect connectivity failures for e
stablished
adjacencies faster than the OSPF Hello dead timer detection and to trigger
rerouting of traffic around the failure. The use of BFD for monitoring rerouting of traffic around the failure. The use of BFD for monitoring
routing protocol adjacencies is described in <xref routing protocol adjacencies is described in <xref target="RFC5882" format
target="RFC5882"/>.</t> ="default"/>.</t>
<t>When BFD monitoring is enabled for OSPF adjacencies by the network <t>When BFD monitoring is enabled for OSPF adjacencies by the network
operator, the BFD session is bootstrapped based on the neighbor address operator, the BFD session is bootstrapped based on the neighbor address
information discovered by the exchange of OSPF Hello packets. Faults in information discovered by the exchange of OSPF Hello packets. Faults in
the bidirectional forwarding detected via BFD then result in the OSPF the bidirectional forwarding detected via BFD then result in the OSPF
adjacency being brought down. A degraded or poor quality link may result adjacency being brought down. A degraded or poor-quality link may result
in intermittent packet drops. In such scenarios, in implementations in intermittent packet drops. In such scenarios, implementations prior to
prior to the extensions specified in this document, an OSPF adjacency the extensions specified in this document may still get an OSPF adjacency estab
may still get established over such a link but given the more aggressive lished over such a link; however, given the more aggressive monitoring intervals
monitoring intervals supported by BFD, a BFD session may not get supported by BFD, a BFD session may not get established and/or may flap. The t
established and/or may flap over it. The traffic that gets forwarded raffic forwarded over such a link would
over such a link would experience packet drops and the failure of the experience packet drops, and the failure of the BFD session establishment
BFD session establishment would not enable fast routing convergence. will not enable fast routing convergence. OSPF adjacency flaps may
OSPF adjacency flaps may occur over such links as OSPF brings up the occur over such links when OSPF brings up the adjacency only for it to be
adjacency only for it to be brought down again by BFD.</t> brought down again by BFD.</t>
<t>To avoid the routing churn associated with these scenarios, it would <t>To avoid the routing churn associated with these scenarios, it would
be beneficial to not allow OSPF to establish an adjacency until a BFD be beneficial not to allow OSPF to establish an adjacency until a BFD
session is successfully established and has stabilized. However, this session is successfully established and has stabilized.
However, this
would preclude the OSPF operation in an environment where not all OSPF would preclude the OSPF operation in an environment where not all OSPF
routers both support BFD and have it enabled on the link. A solution is routers support BFD and have it enabled on the link. A solution is
to block OSPF adjacency establishment until a BFD session is established to block OSPF adjacency establishment until a BFD session is established
as long as both neighbors advertise such a requirement. Such a mode of as long as both neighbors advertise such a requirement. Such a mode of
OSPF BFD usage is referred to as "strict-mode". It introduces the OSPF BFD usage is referred to as "strict-mode". Strict-mode introduces
signaling support in OSPF to achieve the blocking of adjacency formation signaling support in OSPF to achieve the blocking of adjacency formation
until BFD session establishment as described in section 4.1 of <xref until BFD session establishment occurs, as described in <xref target="RFC5
target="RFC5882"/>.</t> 882" sectionFormat="of" section="4.1"/>.</t>
<t>This document specifies the OSPF protocol extensions using Link-Local <t>This document specifies the OSPF protocol extensions using Link-Local
Signaling (LLS) <xref target="RFC5613"/> for a router to indicate to its Signaling (LLS) <xref target="RFC5613" format="default"/> for a router
neighbor the willingness to require BFD strict-mode for OSPF adjacency to indicate to its neighbor the willingness to require BFD strict-mode for
establishment (refer to <xref target="BBIT"/>). It also introduces an OSPF
extension for OSPFv3 Link-Local Signalling (LLS) of the interface IPv4 adjacency establishment (refer to <xref target="BBIT"
address (refer to <xref target="IFADDRTLV"/>) to be used for the BFD format="default"/>). It also introduces an extension to
session setup when OSPFv3 is used for an IPv4 address-family (AF) OSPFv3 LLS of the interface IPv4 address (refer
to <xref target="IFADDRTLV" format="default"/>) to be used for the BFD
session setup when OSPFv3 is used for an IPv4 Address Family (AF)
instance.</t> instance.</t>
<t>This document updates <xref target="RFC2328" format="default"/> by augm
<t>This document updates <xref target="RFC2328"/> by augmenting the OSPF enting the OSPF
neighbor state machine with a check for BFD session up before neighbor state machine with a check for BFD session up before
progression from Init to Two-Way state when operating in OSPF BFD progression from Init to 2-Way state when operating in OSPF BFD
strict-mode.</t> strict-mode.</t>
<t>The extensions and procedures for OSPF BFD strict-mode also apply for <t>The extensions and procedures for OSPF BFD strict-mode also apply for
adjacency over virtual links using BFD multi-hop <xref adjacency over virtual links using BFD multi-hop <xref target="RFC5883" fo
target="RFC5883"/> procedures.</t> rmat="default"/> procedures.</t>
<t>A similar functionality for IS-IS is specified in <xref target="RFC6213
<t>A similar functionality for IS-IS is specified <xref " format="default"/>.</t>
target="RFC6213"/>.</t> <section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="BBIT" numbered="true" toc="default">
<section anchor="BBIT" title="LLS B-bit Flag"> <name>LLS B-Bit Flag</name>
<t>This document defines the B-bit in the LLS Type 1 Extended Options <t>This document defines the B-bit in the LLS Type 1 Extended Options
and Flags field. This bit is defined for the LLS block included in Hello and Flags. This bit is defined for the LLS block that is included
and Database Description (DD) packets and indicates that BFD is enabled in Hello and Database Description (DD) packets. The B-bit indicates that
on the link and that the router requests OSPF BFD strict-mode. <xref BFD is enabled on the link and that the router requests OSPF BFD
target="IANA"/> describes the position of the B-bit.</t> strict-mode. <xref target="IANA" format="default"/> describes the
position of the B-bit.</t> <t>A router <bcp14>MUST</bcp14> include the
<t>A router MUST include the LLS block with the B-bit set in the LLS LLS block with the B-bit set in the LLS Type 1 Extended Options and
Type 1 Extended Options and Flags TLV in its Hello and DD packets when Flags in its Hello and DD packets when OSPF BFD strict-mode is
OSPF BFD strict-mode is enabled on the link.</t> enabled on the link.</t>
</section> </section>
<section anchor="IFADDRTLV" numbered="true" toc="default">
<section anchor="IFADDRTLV" title="Local Interface IPv4 Address TLV"> <name>Local Interface IPv4 Address TLV</name>
<t>The Local Interface IPv4 Address TLV is an LLS TLV defined for OSPFv3 <t>The Local Interface IPv4 Address TLV is an LLS TLV defined for OSPFv3
IPv4 AF instance <xref target="RFC5838"/> protocol operation as IPv4 AF instance <xref target="RFC5838" format="default"/> protocol operat
described in <xref target="OSPFV3AF"/>.</t> ion as
described in <xref target="OSPFV3AF" format="default"/>.</t>
<t>It has the following format:<figure> <t>It has the following format:</t>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface IPv4 Address | | Local Interface IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>where:</t>
where: <dl newline="false" spacing="normal">
]]></artwork> <dt>Type:</dt>
</figure><list style="hanging"> <dd>21</dd>
<t>Type: 21</t> <dt>Length:</dt>
<dd>4 octets</dd>
<t>Length: 4 octets</t> <dt>Local Interface IPv4 Address:</dt>
<dd>The primary IPv4 address of the local interface.</dd>
<t>Local Interface IPv4 Address: The primary IPv4 address of the </dl>
local interface.</t>
</list></t>
</section> </section>
<section anchor="PROCEDURES" numbered="true" toc="default">
<section anchor="PROCEDURES" title="Procedures"> <name>Procedures</name>
<t>A router supporting OSPF BFD strict-mode advertises this capability <t>A router supporting OSPF BFD strict-mode advertises this capability
through its Hello packets as described in <xref target="BBIT"/>. When a through its Hello packets as described in <xref target="BBIT" format="defa ult"/>. When a
router supporting OSPF BFD strict-mode discovers a new neighbor router router supporting OSPF BFD strict-mode discovers a new neighbor router
that also supports OSPF BFD strict-mode, it will establish a BFD session that also supports OSPF BFD strict-mode, it will establish a BFD session w
first with that neighbor before bringing up the OSPF adjacency as ith that neighbor first before bringing up the OSPF adjacency as
described further in this section.</t> described further in this section.</t>
<t>This document updates the OSPF neighbor state machine as described in <t>This document updates the OSPF neighbor state machine as described in
<xref target="RFC2328"/>. Specifically, the operations related to the <xref target="RFC2328" format="default"/>. Specifically, the operations re
Init state are modified as below when OSPF BFD strict-mode is used:</t> lated to the
Init state are modified as described below when OSPF BFD strict-mode is us
<t>Init (without OSPF BFD strict-mode)</t> ed:</t>
<dl newline="true" spacing="normal">
<t><list style="hanging"> <dt>Init (without OSPF BFD strict-mode):</dt>
<t>In this state, a Hello packet has recently been received from the <dd>In this state, a Hello packet has recently been received from the
neighbor. However, bidirectional communication has not yet been neighbor. However, bidirectional communication has not yet been
established with the neighbor (i.e., the router itself did not established with the neighbor (i.e., the router itself did not
appear in the neighbor's Hello packet). All neighbors in this state appear in the neighbor's Hello packet). All neighbors in this state
(or higher) are listed in the Hello packets sent from the associated (or higher) are listed in the Hello packets sent from the associated
interface.</t> interface.</dd>
</list></t> <dt>Init (with OSPF BFD strict-mode):</dt>
<dd>In this state, a Hello packet has recently been received from the
<t>Init (with OSPF BFD strict-mode)</t> neighbor. However, bidirectional communication has not yet been
established with the neighbor (i.e., the router itself did not appear
<t><list style="hanging"> in the neighbor's Hello packet). BFD session establishment with the
<t>In this state, a Hello packet has recently been received from the neighbor is requested if it's not already completed (e.g., in the
neighbor. However, bidirectional communication has not yet been event of transition from 2-Way state). Neighbors in
established with the neighbor (i.e., the router itself did not Init state or higher will be listed in Hello packets associated
appear in the neighbor's Hello packet). BFD session establishment with the interface if they either have a corresponding BFD session
with the neighbor is requested, if not already completed (e.g., in established or have not advertised OSPF BFD strict-mode in the LLS
the event of transition from 2-way state). Neighbors in Init state Type 1 Extended Options and Flags advertised in the Hello packet.</dd>
or higher will be listed in Hello packets associated with the </dl>
interface if they either have a corresponding BFD session <t>When the neighbor state transitions to Down state, the removal of
established or have not advertised OSPF BFD strict-mode in the Hello the BFD session associated with that neighbor is requested by OSPF;
packet LLS Extended Options and Flags.</t>
</list></t>
<t>Whenever the neighbor state transitions to Down state, the removal of
the BFD session associated with that neighbor is requested by OSPF and
subsequent BFD session establishment is similarly requested by OSPF upon subsequent BFD session establishment is similarly requested by OSPF upon
transitioning into Init state. This may result in the deletion and transitioning into Init state.
creation of the BFD session respectively when OSPF is the only client This may result in BFD session deletion and creation, respectively, when O
SPF is the only client
interested in the BFD session with the neighbor address.</t> interested in the BFD session with the neighbor address.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> wait for BFD session
<t>An implementation MUST NOT wait for BFD session establishment in Init establishment in Init state unless OSPF BFD strict-mode is enabled by
state unless OSPF BFD strict-mode is enabled by the operator on the the operator on the interface and the specific neighbor indicates OSPF
interface and the specific neighbor indicates OSPF BFD strict-mode BFD strict-mode capability via the LLS Type 1 Extended Options and Flags a
capability via its Hello LLS options. When BFD is enabled, but OSPF BFD dvertised in the Hello packet. When BFD is
strict-mode has not been signaled by both neighbors, an implementation enabled, but OSPF BFD strict-mode has not been signaled by both
SHOULD start BFD session establishment only in 2-Way state or greater neighbors, an implementation <bcp14>SHOULD</bcp14> start BFD session
state. This makes it possible for an OSPF router to support BFD establishment only in 2-Way or greater state. This makes it
operation in both strict-mode and normal mode across different possible for an OSPF router to support BFD operation in both strict-mode
interfaces or even different neighbors on the same multi-access and normal mode across different interfaces or even across different neigh
interface.</t> bors
on the same multi-access interface.</t>
<t>Once the OSPF state machine has moved beyond the Init state, any <t>Once the OSPF state machine has moved beyond the Init state, any
change in the B-bit advertised in subsequent Hello packets MUST NOT change in the B-bit advertised in subsequent Hello packets <bcp14>MUST NOT </bcp14>
result in any trigger in either the OSPF adjacency or the BFD session result in any trigger in either the OSPF adjacency or the BFD session
management (i.e., the B-bit is considered only when in Init state). management (i.e., the B-bit is considered only when in Init state).
Disabling BFD (or OSPF BFD strict-mode) on an OSPF interface would
result in it not setting the B-bit in its subsequent Hello LLS options.
Disabling OSPF BFD strict-mode has no effect on BFD operations and would
not result in bringing down of any established BFD sessions. Disabling
BFD would result in the BFD session being brought down due to Admin
reason <xref target="RFC5882"/> and hence would not bring down the OSPF
adjacency.</t>
Disabling BFD (or OSPF BFD strict-mode) on an OSPF interface would
result in it not setting the B-bit in the LLS Type 1 Extended Options and
Flags advertised in subsequent Hello packets.
Disabling OSPF BFD strict-mode has no effect on BFD operations and would
not result in the bringing down of any established BFD sessions. Disablin
g BFD would result in the BFD session being brought down due to AdminDown State
(described in <xref target="RFC5882" sectionFormat="of" section="3.2"/>); hence,
it would not bring
down the OSPF adjacency.</t>
<t>When BFD is enabled on an interface over which we already have an <t>When BFD is enabled on an interface over which we already have an
existing OSPF adjacency, it would result in the router setting the B-bit existing OSPF adjacency, it would result in the router setting the B-bit
in its subsequent Hello packets and initiation of BFD session in its subsequent Hello packets and the initiation of BFD session
establishment to the neighbor. If the adjacency is already up (i.e., in establishment to the neighbor.
its terminal state of Full or 2-way with non-DR routers on a
If the adjacency is already up (i.e., in
its terminal state of Full or 2-Way with routers that are not designated r
outers on a
multi-access interface) with a neighbor that also supports OSPF BFD multi-access interface) with a neighbor that also supports OSPF BFD
strict-mode, then an implementation SHOULD NOT bring this adjacency down strict-mode, then an implementation <bcp14>SHOULD NOT</bcp14> bring this a djacency down
into the Init state to avoid disruption to routing operations and into the Init state to avoid disruption to routing operations and
instead use the OSPF BFD strict-mode wait only after a transition to instead use the OSPF BFD strict-mode wait only after a transition to
Init state. However, if the adjacency is not up, then an implementation Init state. However, if the adjacency is not up, then an implementation
MAY bring such an adjacency down so it can use the OSPF BFD strict-mode <bcp14>MAY</bcp14> bring such an adjacency down so it can use the OSPF BFD strict-mode
for its adjacency establishment.</t> for its adjacency establishment.</t>
<section anchor="OSPFV3AF" numbered="true" toc="default">
<section anchor="OSPFV3AF" title="OSPFv3 IPv4 Address-Family Specifics"> <name>OSPFv3 IPv4 AF Specifics</name>
<t>Multiple AF support in OSPFv3 <xref target="RFC5838"/> requires the <t>Support for multiple AFs in OSPFv3 <xref target="RFC5838"
use of an IPv6 link-local address as the source address for Hello format="default"/> requires the use of an IPv6 link-local address as
packets even when forming adjacencies for IPv4 AF instances. In most the source address for Hello packets, even when forming adjacencies
deployments of OSPFv3 IPv4 AF, it is required that BFD is used to for IPv4 AF instances. In most deployments of OSPFv3 IPv4 AFs, it is
monitor and verify IPv4 data plane connectivity between the routers on required that BFD is used to monitor and verify IPv4 data plane
the link and, hence, the BFD session is setup using IPv4 neighbor connectivity between the routers on the link; hence, the BFD session
addresses. The IPv4 neighbor address on the interface is learned only is set up using IPv4 neighbor addresses.
later in the adjacency formation process when the neighbor's Link-LSA The IPv4 neighbor address on
is received. This results in the setup of the BFD IPv4 session either the interface is learned only later in the adjacency formation process
after the adjacency is established or later in the adjacency formation when the neighbor's Link-LSA (Link State Advertisement) is received. Thi
s
results in the setup of the BFD IPv4 session either after the
adjacency is established or later in the adjacency formation
sequence.</t> sequence.</t>
<t>To operate in OSPF BFD strict-mode, it is necessary for an OSPF <t>To operate in OSPF BFD strict-mode, it is necessary for an OSPF
router to learn its neighbor's IPv4 link address during the Init state router to learn its neighbor's IPv4 link address during the Init state
of adjacency formation (ideally when it receives the first hello). The of adjacency formation (ideally, when it receives the first Hello). The
use of the Local Interface IPv4 Address TLV (as defined in <xref use of the Local Interface IPv4 Address TLV (as defined in <xref
target="IFADDRTLV"/>) in the LLS block of OSPFv3 Hello packets for target="IFADDRTLV" format="default"/>) in the LLS block advertised in OS
IPv4 AF instances makes this possible. Implementations that support PFv3
OSPF BFD strict-mode for OSPFv3 IPv4 AF instances MUST include the Hello packets for IPv4 AF instances makes this
Local Interface IPv4 Address TLV in the LLS block of their Hello possible. Implementations that support OSPF BFD
packets whenever the B-bit is also set in the LLS Options and Flags strict-mode for OSPFv3 IPv4 AF instances <bcp14>MUST</bcp14> include the Loca
field. A receiver MUST ignore the B-bit (i.e., not operate in strict l
mode for BFD) when the Local Interface IPv4 Address TLV is not present Interface IPv4 Address TLV in the LLS block advertised in their Hello packets
in OSPFv3 Hello messages for IPv4 AF OSPFv3 instances.</t> whenever the B-bit is also set in the LLS Type 1 Extended Options and Flags.
A receiver
<bcp14>MUST</bcp14> ignore the B-bit (i.e., not operate in strict-mode
for BFD) when the Local Interface IPv4 Address TLV is not present in
OSPFv3 Hello messages for OSPFv3 IPv4 AF instances.</t>
</section> </section>
<section anchor="GR" numbered="true" toc="default">
<section anchor="GR" title="Graceful Restart Considerations"> <name>Graceful Restart Considerations</name>
<t>An implementation needs to handle scenarios where both graceful <t>An implementation needs to handle scenarios where both graceful
restart (GR) and the OSPF BFD strict-mode are deployed together. The restart (GR) and the OSPF BFD strict-mode are deployed together. The gr
GR aspects discussed in section 3.3 of <xref target="RFC5882"/> also aceful restart aspects related to process restart scenarios discussed in <xref t
apply with OSPF BFD strict-mode. Additionally, in OSPF BFD arget="RFC5882" sectionFormat="of"
strict-mode, since the OSPF adjacency formation is delayed until the section="3.3"/> also apply with OSPF BFD strict-mode. Additionally, since the
BFD session establishment, the resultant delay in adjacency formation OSPF adjacency formation is delayed until the BFD session establishment in
may affect or break the GR-based recovery. In such cases, it is OSPF BFD strict-mode, the resultant delay in adjacency formation may affect or
RECOMMENDED that the GR timers are set such that they provide break the GR-based recovery. In such cases, it is <bcp14>RECOMMENDED</bcp14>
sufficient time to allow for normal BFD session establishment that the GR timers are set such that they provide sufficient time to allow for
delays.</t> normal BFD session establishment delays.</t>
</section> </section>
</section> </section>
<section anchor="OPS" numbered="true" toc="default">
<section anchor="OPS" title="Operations &amp; Management Considerations"> <name>Operations and Management Considerations</name>
<t>An implementation SHOULD report the BFD session status along with the <t>An implementation <bcp14>SHOULD</bcp14> report the BFD session status a
long with the
OSPF Init adjacency state when OSPF BFD strict-mode is enabled and OSPF Init adjacency state when OSPF BFD strict-mode is enabled and
support logging operations on neighbor state transitions that include support logging operations on neighbor state transitions that include
the BFD events. This allows an operator to detect scenarios where an the BFD events. This allows an operator to detect scenarios where an
OSPF adjacency may be stuck waiting for BFD session establishment.</t> OSPF adjacency may be stuck waiting for BFD session establishment.</t>
<t>In network deployments with noisy or degraded links with intermittent <t>In network deployments with noisy or degraded links with intermittent
packet loss, BFD sessions may flap resulting in OSPF adjacency flaps. packet loss, BFD sessions may flap, resulting in OSPF adjacency flaps.
This in turn may cause routing churn. The use of OSPF BFD strict-mode In turn, this may cause routing churn. The use of OSPF BFD strict-mode
along with mechanisms such as hold-down (a delay in the initial OSPF along with mechanisms such as hold-down (a delay in bringing up the initia
adjacency bringup following BFD session establishment) and/or dampening l OSPF adjacency following BFD
(a delay in the OSPF adjacency bringup following failure detected by session establishment) and/or dampening (a delay in bringing up the OSPF adjacen
BFD) may help reduce the frequency of adjacency flaps and therefore cy following failure detected by BFD) may help reduce the
reduce the associated routing churn. The details of these mechanisms are frequency of adjacency flaps and therefore reduce the associated
routing churn. The details of these mechanisms are
outside the scope of this document.</t> outside the scope of this document.</t>
<t><xref target="I-D.ietf-ospf-yang"/> specifies the base OSPF YANG <t><xref target="RFC9129" format="default"/> specifies the base OSPF YANG
model. The required configuration and operational elements for this module. The required configuration and operational elements for this
feature are expected to be introduce as augmentation to this base OSPF feature are expected to be introduced as augmentation to this base OSPF
YANG model.</t> YANG module.</t>
</section> </section>
<section anchor="BACKW" numbered="true" toc="default">
<section anchor="BACKW" title="Backward Compatibility"> <name>Backward Compatibility</name>
<t>An implementation MUST support OSPF adjacency formation and <t>An implementation <bcp14>MUST</bcp14> support OSPF adjacency formation
and
operations with a neighbor router that does not advertise the OSPF BFD operations with a neighbor router that does not advertise the OSPF BFD
strict-mode capability - both when that neighbor router does not support strict-mode capability: both when that neighbor router does not support
BFD and when it does support BFD but does not signal the OSPF BFD BFD and when it does support BFD but does not signal the OSPF BFD
strict-mode as described in this document. Implementations MAY provide a strict-mode as described in this document. Implementations <bcp14>MAY</bcp 14> provide a
local configuration option to force BFD operation only in OSPF BFD local configuration option to force BFD operation only in OSPF BFD
strict-mode (i.e, adjacency will not come up unless BFD session is strict-mode (i.e, adjacency will not come up unless BFD session is
established). In this case, an OSPF adjacency with a neighbor that does established). In this case, an OSPF adjacency with a neighbor that does
not support OSPF BFD strict-mode would not be established successfully. not support OSPF BFD strict-mode would not be established successfully.
Implementations MAY provide a local configuration option to enable BFD Implementations <bcp14>MAY</bcp14> provide a local configuration option to
without the OSPF BFD strict-mode which results in the router not enable BFD
without the OSPF BFD strict-mode, which results in the router not
advertising the B-bit and BFD operation being performed in the same way advertising the B-bit and BFD operation being performed in the same way
as prior to this specification.</t> as prior to this specification.</t>
<t>The signaling specified in this document happens at a link-local <t>The signaling specified in this document happens at a link-local
level between routers on that link. A router that does not support this level between routers on that link. A router that does not support this
specification would ignore the B-bit in the LLS block of Hello packets specification would ignore the B-bit in the LLS block advertised in Hello
from its neighbors and continue to establish BFD sessions, if enabled, packets
from its neighbors and continue to establish BFD sessions (if enabled)
without delaying the OSPF adjacency formation. Since a router that does without delaying the OSPF adjacency formation. Since a router that does
not support this specification would not have set the B-bit in the LLS not support this specification would not have set the B-bit in the LLS
block of its own Hello packets, its neighbor routers supporting this block advertised in its own Hello packets, its neighbor routers supporting this
specification would not use OSPF BFD strict-mode with such OSPF routers. specification would not use OSPF BFD strict-mode with such OSPF routers.
As a result, the behavior would be the same as without this As a result, the behavior would be the same as without this
specification. Therefore, there are no backward compatibility issues or specification. Therefore, there are no backward compatibility issues or
implementations considerations beyond what is specified herein.</t> implementation considerations beyond what is specified herein.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This specification makes the following updates under the "Open <t>This specification makes the following updates under the "Open
Shortest Path First (OSPF) Link Local Signaling (LLS) - Shortest Path First (OSPF) Link Local Signaling (LLS) -
Type/Length/Value Identifiers (TLV)" parameters.</t> Type/Length/Value Identifiers (TLV)" parameters.</t>
<ul><li>In the "LLS Type 1 Extended Options and Flags" registry, the B-bit
<t>IANA is requested to make permanent the following values that have has been assigned the bit position 0x00000010.</li>
been assigned via early allocation:</t> <li>In the "Link Local Signaling TLV Identifiers (LLS Types)" registry,
the Type 21 has been assigned to the Local Interface IPv4 Address TLV.</li
<t>o In the "LLS Type 1 Extended Options and Flags" registry, the B-bit >
is assigned the bit position 0x00000010</t> </ul>
<t>o In the "Link Local Signaling TLV Identifiers (LLS Types)" registry,
the Type 21 is assigned to the Local Interface IPv4 Address TLV</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations for "OSPF Link-Local Signaling" <xref
target="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 <xref target="RFC5709"/><xref
target="RFC7474"/>, then the Cryptographic Authentication TLV <xref
target="RFC5613"/> MUST also be used to protect the contents of the LLS
block.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security considerations for "<xref target="RFC5613" format="title"/
>" <xref target="RFC5613" format="default"/> also apply to the extension describ
ed in this
document.
<section anchor="Acknowledgements" title="Acknowledgements"> Inappropriate use of the B-bit in the LLS block of an OSPF Hello message could
<t>The authors would like to acknowledge the review and inputs from Acee prevent an OSPF adjacency from forming or lead to the failure of detecting
Lindem, Manish Gupta, Balaji Ganesh, Les Ginsberg, Robert Raszuk, Gyan bidirectional forwarding failures. If authentication is being used in the OSPF
Mishra, Muthu Arul Mozhi Perumal, Russ Housley, and Wes Hardaker.</t> routing domain <xref target="RFC5709" format="default"/> <xref target="RFC7474"
format="default"/>, then the Cryptographic Authentication TLV <xref
<t>The authors would like to acknowledge Dylan van Oudheusden for target="RFC5613" format="default"/> <bcp14>MUST</bcp14> also be used to
highlighting the problems in using OSPF BFD strict-mode for BFD session protect the contents of the LLS block.</t>
for IPv4 AF instance with OSPFv3 and Baalajee S for his suggestions on
the approach to address it.</t>
<t>The authors would like to thank John Scudder for his AD review and
suggestions to improve the document.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <name>References</name>
FC.2328.xml"?> <references>
<name>Normative References</name>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
FC.5340.xml"?> 328.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R 340.xml"/>
FC.5882.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
882.xml"/>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
FC.2119.xml"?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R 174.xml"/>
FC.8174.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
613.xml"/>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.5613.xml"?> 838.xml"/>
</references>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <references>
FC.5838.xml"?> <name>Informative References</name>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
880.xml"/>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R 883.xml"/>
FC.5880.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
213.xml"/>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.5883.xml"?> 474.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R 709.xml"/>
FC.6213.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.7474.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R FC.5709.xml"?> <!-- [I-D.ietf-ospf-yang] Published as RFC 9129 -->
<?rfc include='reference.I-D.ietf-ospf-yang.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
129.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to acknowledge the review and inputs from
<contact fullname="Acee Lindem"/>, <contact fullname="Manish Gupta"/>,
<contact fullname="Balaji Ganesh"/>, <contact fullname="Les Ginsberg"/>,
<contact fullname="Robert Raszuk"/>, <contact fullname="Gyan Mishra"/>,
<contact fullname="Muthu Arul Mozhi Perumal"/>, <contact fullname="Russ
Housley"/>, and <contact fullname="Wes Hardaker"/>.</t>
<t>The authors would like to acknowledge <contact fullname="Dylan van
Oudheusden"/> for highlighting the problems in using OSPF BFD
strict-mode for BFD sessions for OSPFv3 IPv4 AF instances and
<contact fullname="Baalajee S"/> for his suggestions on the approach to
address it.</t>
<t>The authors would like to thank <contact fullname="John Scudder"/>
for his AD review and suggestions to improve the document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 86 change blocks. 
339 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.48.