summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7884.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7884.txt')
-rw-r--r--doc/rfc/rfc7884.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc7884.txt b/doc/rfc/rfc7884.txt
new file mode 100644
index 0000000..6fa4005
--- /dev/null
+++ b/doc/rfc/rfc7884.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al. Standards Track [Page 1]
+
+RFC 7884 S-BFD Discriminators in OSPF July 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al. Standards Track [Page 2]
+
+RFC 7884 S-BFD Discriminators in OSPF July 2016
+
+
+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.
+
+
+
+
+
+Pignataro, et al. Standards Track [Page 3]
+
+RFC 7884 S-BFD Discriminators in OSPF July 2016
+
+
+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
+
+
+
+
+Pignataro, et al. Standards Track [Page 4]
+
+RFC 7884 S-BFD Discriminators in OSPF July 2016
+
+
+ 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.
+
+
+
+
+Pignataro, et al. Standards Track [Page 5]
+
+RFC 7884 S-BFD Discriminators in OSPF July 2016
+
+
+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>.
+
+
+
+
+
+
+
+Pignataro, et al. Standards Track [Page 6]
+
+RFC 7884 S-BFD Discriminators in OSPF July 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al. Standards Track [Page 7]
+