OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection
(S-BFD) Target DiscriminatorsCisco Systems, Inc.cpignata@cisco.comIonos Networksmanav@ionosnetworks.comHuawei Technologies aldrin.ietf@gmail.comNokiatrilok.ranganatha@nokia.comBFDseamless BFDnegotiation freelabel verificationsegment routingIPThis document defines a new OSPF Router Information (RI) TLV that
allows OSPF routers to flood the Seamless Bidirectional Forwarding
Detection (S-BFD) Discriminator values associated with a target network
identifier. This mechanism is applicable to both OSPFv2 and OSPFv3.
Seamless Bidirectional Forwarding Detection (S-BFD), specified in
, is a simplified mechanism for using BFD
with many negotiations eliminated. This is achieved by using
4&nbhy;octet discriminators, unique within an administrative domain,
to identify the network targets. These S-BFD Discriminators can be
advertised by the IGPs, and this document concerns itself with OSPF.
Specifically, this document defines a new TLV (named the S-BFD
Discriminator TLV) to be carried within the OSPF Router Information (RI)
Link State Advertisement (LSA) .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC
2119.
This document implicitly defines a relationship between OSPF and S-BFD.
S-BFD assigns one or more discriminators to each S-BFD reflector node.
OSPF, in turn, learns about these from S-BFD and floods them in the newly
defined TLV. After this information is flooded, it is stored in all the OSPF
nodes such that S-BFD initiators can map out target nodes to target
discriminators and can therefore construct the S-BFD probe.
When multiple S-BFD Discriminators are advertised, how a given discriminator
is mapped to a specific use case is out of scope for this document.
This extension makes use of the Router Information (RI) Opaque LSA,
defined in , for both OSPFv2
and OSPFv3 by
defining a new OSPF Router Information (RI) TLV: the S-BFD Discriminator
TLV.
The S-BFD Discriminator TLV is OPTIONAL. Upon receipt
of the TLV, a router may decide to install the
S-BFD Discriminator in the BFD target identifier table.
In the presence of multiple instances of the OSPFv2/OSPFv3
Router Information LSA, the S-BFD Discriminators for an OSPF router
are the union of all discriminators advertised in all instances of
the S-BFD Discriminator TLV (see ) in all
advertised non-MaxAge OSPF Router Information LSAs.
The format of the S-BFD Discriminator TLV is as follows: Type - S-BFD Discriminator TLV Type (11)This field represents the total length of the
discriminator(s) that appears in the Value field, in octets. Each
discriminator is 4 octets, so the Length is four times the number
of discriminators included in the TLV. There is no optional padding for
this field.
The Value field of the TLV includes
the S-BFD network target Discriminator value or values.Routers that do not recognize the S-BFD Discriminator TLV Type will ignore
the TLV and therefore will not learn S-BFD
Discriminators via OSPF.The S-BFD Discriminator TLV is advertised within OSPFv2 Router Information
LSAs (Opaque type of 4 and Opaque ID of 0) or OSPFv3 Router Information
LSAs (function code of 12), which are defined in .
As such, elements of this procedure are inherited from those defined
in .
The flooding scope is controlled by the Opaque LSA type (as defined
in ) in OSPFv2 and by the S1/S2 bits (as
defined in ) in OSPFv3. If the flooding scope
is area local, then the S-BFD Discriminator TLV MUST be carried within an
OSPFv2 type 10 Router Information LSA or an OSPFV3 Router Information LSA
with the S1 bit set and the S2 bit clear. If the flooding scope is the
entire IGP domain, then the S-BFD Discriminator TLV MUST be carried
within an OSPFv2 type 11 Router Information LSA or OSPFv3 Router
Information LSA with the S1 bit clear and the S2 bit set.
When the S-BFD reflector is deactivated, the OSPF speaker advertising
a particular S-BFD Discriminator MUST originate a new Router Information
LSA that no longer includes the corresponding S-BFD Discriminator TLV,
provided there are other TLVs in the LSA. If there are no other TLVs in
the LSA, it MUST either send an empty Router Information LSA or purge it by
prematurely aging it.
For intra-area reachability, the S-BFD Discriminator TLV information
regarding a specific target identifier is only considered current and
usable when the router advertising that information is itself reachable
via OSPF calculated paths in the same area of the LSA in which the
S-BFD Discriminator TLV appears. In the case of domain&nbhy;wide
flooding, i.e., where the originator is sitting in a remote area, the
mechanism described in Section 5 of should
be used.
Although the S-BFD Discriminators may change when enabling the S-BFD
functionality or via an explicit configuration event, such changes are
expected to occur very rarely. Such changes in information will
require that the S-BFD Discriminator TLV in OSPF be advertised.
A change in information in the S-BFD Discriminator TLV MUST NOT trigger
any SPF computations at a receiving router.
The S-BFD Discriminator TLV defined in this document does not introduce
any interoperability issues. A router not supporting the S-BFD Discriminator TLV will just silently
ignore the TLV, as specified in .
This document defines OSPF extensions to distribute the S-BFD Discriminator
within an administrative domain. Hence, the security of S-BFD
Discriminator distribution relies on the security of OSPF.
OSPF provides no encryption mechanism for protecting the privacy of
LSAs and, in particular, the privacy of the S-BFD Discriminator
advertisement information. However, this is not a concern, as there
isn't any need to hide the Discriminator value that can be used to
reach the reflectors.
IANA has defined a registry for TLVs carried in the Router Information LSA
defined in . IANA has assigned a new TLV
codepoint (11) for the S-BFD Discriminator TLV in the "OSPF Router
Information (RI) TLVs" registry.
Seamless Bidirectional Forwarding Detection (S-BFD)
The authors would like to thank Nobo Akiya, Les Ginsberg, Mach Chen,
and Peter Psenak for insightful comments and useful suggestions.