S-BFD in OSPF: OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators
How OSPF routers tell each other which S-BFD discriminators reach which targets.
Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, "OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators", RFC 7884, DOI 10.17487/RFC7884, July 2016, <https://www.rfc-editor.org/info/rfc7884>.
@misc{rfc7884,
series = {Request for Comments},
number = 7884,
howpublished = {RFC 7884},
publisher = {RFC Editor},
doi = {10.17487/RFC7884},
url = {https://www.rfc-editor.org/info/rfc7884},
author = {C. Pignataro and M. Bhatia and S. Aldrin and T. Ranganath},
title = {{OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators}},
pagetotal = 7,
year = 2016,
month = jul,
} RFC text
Contents
Internet Engineering Task Force (IETF) C. Pignataro
Request for Comments: 7884 Cisco
Category: Standards Track M. Bhatia
ISSN: 2070-1721 Ionos Networks
S. Aldrin
Huawei Technologies
T. Ranganath
Nokia
July 2016
OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection
(S-BFD) Target Discriminators
Abstract
This 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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7884.
Copyright Notice
Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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 ....................................................3
1.1. Relationship between OSPF and S-BFD ........................3
2. Implementation ..................................................3
2.1. S-BFD Discriminator TLV ....................................4
2.2. Flooding Scope .............................................4
3. Backward Compatibility ..........................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
Acknowledgements ...................................................7
Authors' Addresses .................................................7
1. Introduction
Seamless Bidirectional Forwarding Detection (S-BFD), specified in
[RFC7880], is a simplified mechanism for using BFD with many
negotiations eliminated. This is achieved by using 4-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) [RFC7770].
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 [RFC2119].
1.1. Relationship between OSPF and S-BFD
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.
2. Implementation
This extension makes use of the Router Information (RI) Opaque LSA,
defined in [RFC7770], for both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]
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 Section 2.1) in all advertised non-MaxAge OSPF
Router Information LSAs.
2.1. S-BFD Discriminator TLV
The format of the S-BFD Discriminator TLV is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator 2 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator n (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type - S-BFD Discriminator TLV Type (11)
Length - 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.
Discriminator(s) - 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 [RFC7770] and therefore will not learn S-BFD
Discriminators via OSPF.
2.2. Flooding Scope
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
[RFC7770]. As such, elements of this procedure are inherited from
those defined in [RFC7770].
The flooding scope is controlled by the Opaque LSA type (as defined
in [RFC5250]) in OSPFv2 and by the S1/S2 bits (as defined in
[RFC5340]) 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-wide flooding, i.e., where the originator is sitting in a
remote area, the mechanism described in Section 5 of [RFC5250] 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.
3. Backward Compatibility
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 [RFC7770].
4. Security Considerations
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.
5. IANA Considerations
IANA has defined a registry for TLVs carried in the Router
Information LSA defined in [RFC7770]. IANA has assigned a new TLV
codepoint (11) for the S-BFD Discriminator TLV in the "OSPF Router
Information (RI) TLVs" registry.
Value TLV Name Reference
----- -------- ----------
11 S-BFD RFC 7884
Discriminator
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <http://www.rfc-editor.org/info/rfc7770>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<http://www.rfc-editor.org/info/rfc7880>.
6.2. Informative References
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <http://www.rfc-editor.org/info/rfc5250>.
Acknowledgements
The authors would like to thank Nobo Akiya, Les Ginsberg, Mach Chen,
and Peter Psenak for insightful comments and useful suggestions.
Authors' Addresses
Carlos Pignataro
Cisco Systems, Inc.
Email: cpignata@cisco.com
Manav Bhatia
Ionos Networks
Email: manav@ionosnetworks.com
Sam Aldrin
Huawei Technologies
Email: aldrin.ietf@gmail.com
Trilok Ranganath
Nokia
Email: trilok.ranganatha@nokia.com
AI ELI5
On this page
§1Why Advertise Discriminators
Seamless Bidirectional Forwarding Detection (S-BFD, RFC 7880) is a simplified way of using BFD with many negotiations removed. It does this by identifying network targets with 4-octet discriminators that are unique within an administrative domain.
These discriminators can be advertised by the interior gateway protocols. RFC 7884 covers OSPF: it defines a new TLV, the S-BFD Discriminator TLV, carried in the OSPF Router Information (RI) Link State Advertisement (LSA) from RFC 7770. It works for both OSPFv2 and OSPFv3.
For routers to check on each other quickly, each one needs to know the others' ID numbers. This RFC is about sharing those numbers.
§2How OSPF and S-BFD Relate
S-BFD assigns one or more discriminators to each S-BFD reflector node. OSPF learns about them from S-BFD and floods them in the new TLV. Once flooded, the information is stored in all OSPF nodes, so S-BFD initiators can map target nodes to target discriminators and construct the S-BFD probe.
When several discriminators are advertised, the RFC leaves the mapping of a given discriminator to a specific use case out of scope.
A router that wants to ping a friend looks up the friend's number in a shared phone book. OSPF is the phone book that everyone gets a copy of.
§3The S-BFD Discriminator TLV
The TLV is OPTIONAL. It has a 16-bit Type field (value 11), a 16-bit Length field, and then one or more 4-octet discriminators. Length is the total length of the discriminators in octets, so it is four times the number of discriminators, with no optional padding.
If a router has several instances of the OSPFv2 or OSPFv3 Router Information LSA, the discriminators of that router are the union of all discriminators in all advertised non-MaxAge instances. A receiving router may decide to install a discriminator in its BFD target identifier table.
Routers that do not recognize the TLV type ignore it, as RFC 7770 specifies, and so do not learn S-BFD discriminators through OSPF.
The message is a small envelope: a label saying what is inside, a note saying how long it is, and then a list of ID numbers.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 2 bytes | 11 | S-BFD Discriminator TLV type. |
LENGTH | Length | 2 bytes | Four times the number of discriminators. | |
DISC-1 | Discriminator 1 | 4 bytes | First S-BFD network target discriminator. | |
DISC-N | Discriminator 2 ... n (Optional) | 4 bytes | Further discriminators, 4 octets each. |
§4Flooding Scope and Updates
The TLV travels in the Router Information LSA: OSPFv2 Opaque type 4 with Opaque ID 0, or OSPFv3 with function code 12. The flooding scope is chosen by the Opaque LSA type in OSPFv2 and by the S1/S2 bits in OSPFv3.
- Area-local scope: the TLV MUST be in an OSPFv2 type 10 RI LSA, or an OSPFv3 RI LSA with S1 set and S2 clear.
- Whole IGP domain: the TLV MUST be in an OSPFv2 type 11 RI LSA, or an OSPFv3 RI LSA with S1 clear and S2 set.
When an S-BFD reflector is deactivated, the advertising router MUST originate a new RI LSA without the corresponding TLV, provided other TLVs remain. If none remain, it MUST either send an empty RI LSA or purge it by prematurely aging it.
Inside an area, the information is only current and usable when the advertising router is itself reachable through OSPF-calculated paths in that area. For domain-wide flooding from a remote area, the mechanism in Section 5 of RFC 5250 should be used. Discriminators are expected to change very rarely, and a change MUST NOT trigger any SPF computation at a receiving router.
You can choose to share the number with just your neighborhood or with the whole city. If a router stops answering, it takes its number off the list. Changing the list does not make everyone redraw their maps.
§5Compatibility and Security
The TLV introduces no interoperability issues. A router that does not support it silently ignores it, as RFC 7770 specifies.
Security of discriminator distribution relies on the security of OSPF, since the information stays within an administrative domain. OSPF has no encryption for LSAs, so the advertisement is not private. The RFC says this is not a concern, because there is no need to hide the discriminator value that can be used to reach the reflectors.
IANA assigned TLV codepoint 11 for the S-BFD Discriminator TLV in the "OSPF Router Information (RI) TLVs" registry.
Older routers just skip the new note, so nothing gets confused. The number is not a secret, so it is fine that others can read it.