doc: Add RFC documents

1 files changed, 308 insertions, 0 deletions

diff --git a/doc/rfc/rfc9247.txt b/doc/rfc/rfc9247.txt
new file mode 100644
index 0000000..bdc0b8b
--- /dev/null
+++ b/doc/rfc/rfc9247.txt
@@ -0,0 +1,308 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                             Z. Li
+Request for Comments: 9247                                     S. Zhuang
+Category: Standards Track                                         Huawei
+ISSN: 2070-1721                                       K. Talaulikar, Ed.
+                                                            Arrcus, Inc.
+                                                               S. Aldrin
+                                                            Google, Inc.
+                                                             J. Tantsura
+                                                               Microsoft
+                                                               G. Mirsky
+                                                                Ericsson
+                                                               June 2022
+
+
+    BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional
+                      Forwarding Detection (S-BFD)
+
+Abstract
+
+   Seamless Bidirectional Forwarding Detection (S-BFD) defines a
+   simplified mechanism to use Bidirectional Forwarding Detection (BFD)
+   with large portions of negotiation aspects eliminated, thus providing
+   benefits such as quick provisioning as well as improved control and
+   flexibility to network nodes initiating the path monitoring.  The
+   link-state routing protocols (IS-IS and OSPF) have been extended to
+   advertise the S-BFD Discriminators.
+
+   This document defines extensions to the BGP - Link State (BGP-LS)
+   address family to carry the S-BFD Discriminators' information via
+   BGP.
+
+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
+   https://www.rfc-editor.org/info/rfc9247.
+
+Copyright Notice
+
+   Copyright (c) 2022 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
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+     2.1.  Requirements Language
+   3.  BGP-LS Extensions for S-BFD Discriminators
+   4.  IANA Considerations
+   5.  Manageability Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] defines
+   a simplified mechanism to use Bidirectional Forwarding Detection
+   (BFD) [RFC5880] with large portions of negotiation aspects
+   eliminated, thus providing benefits such as quick provisioning as
+   well as improved control and flexibility to network nodes initiating
+   the path monitoring.
+
+   For the monitoring of a service path end to end via S-BFD, the
+   headend node (i.e., Initiator) needs to know the S-BFD Discriminator
+   of the destination/tail-end node (i.e., Responder) of that service.
+   The link-state routing protocols (IS-IS [RFC7883] and OSPF [RFC7884])
+   have been extended to advertise the S-BFD Discriminators.  With this,
+   an Initiator can learn the S-BFD Discriminator for all Responders
+   within its IGP area/level or optionally within the domain.  With
+   networks being divided into multiple IGP domains for scaling and
+   operational considerations, the service endpoints that require end-
+   to-end S-BFD monitoring often span across IGP domains.
+
+   BGP - Link State (BGP-LS) [RFC7752] enables the collection and
+   distribution of IGP link-state topology information via BGP sessions
+   across IGP areas/levels and domains.  The S-BFD Discriminator(s) of a
+   node can thus be distributed along with the topology information via
+   BGP-LS across IGP domains and even across multiple Autonomous Systems
+   (ASes) within an administrative domain.
+
+   This document defines extensions to BGP-LS for carrying the S-BFD
+   Discriminators' information.
+
+2.  Terminology
+
+   This memo makes use of the terms defined in [RFC7880].
+
+2.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  BGP-LS Extensions for S-BFD Discriminators
+
+   BGP-LS [RFC7752] specifies the Node Network Layer Reachability
+   Information (NLRI) for the advertisement of nodes and their
+   attributes using the BGP-LS Attribute.  The S-BFD Discriminators of a
+   node are considered a node-level attribute and are advertised as
+   such.
+
+   This document defines a new BGP-LS Attribute TLV called "S-BFD
+   Discriminators TLV", and its format 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)                 |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 1: S-BFD Discriminators TLV
+
+   where:
+
+   Type:  1032
+
+   Length:  variable.  It MUST be a minimum of 4 octets, and it
+      increments by 4 octets for each additional discriminator.
+
+   Discriminator n:  4 octets each, carrying an S-BFD local
+      discriminator value of the node.  At least one discriminator MUST
+      be included in the TLV.
+
+   The S-BFD Discriminators TLV can be added to the BGP-LS Attribute
+   associated with the Node NLRI that originates the corresponding
+   underlying IGP TLV/sub-TLV as described below.  This information is
+   derived from the protocol-specific advertisements as follows:
+
+   *  IS-IS, as defined by the S-BFD Discriminators sub-TLV in
+      [RFC7883].
+
+   *  OSPFv2/OSPFv3, as defined by the S-BFD Discriminator TLV in
+      [RFC7884].
+
+4.  IANA Considerations
+
+   IANA has permanently allocated the following code point in the "BGP-
+   LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
+   TLVs" registry.  The column "IS-IS TLV/Sub-TLV" defined in the
+   registry does not require any value and should be left empty.
+
+         +================+======================+===============+
+         | TLV Code Point | Description          | Reference     |
+         +================+======================+===============+
+         | 1032           | S-BFD Discriminators | This document |
+         +----------------+----------------------+---------------+
+
+          Table 1: S-BFD Discriminators TLV Code Point Allocation
+
+5.  Manageability Considerations
+
+   The new protocol extensions introduced in this document augment the
+   existing IGP topology information that was distributed via BGP-LS
+   [RFC7752].  Procedures and protocol extensions defined in this
+   document do not affect BGP protocol operations and management other
+   than as discussed in "Manageability Considerations" (Section 6) of
+   [RFC7752].  Specifically, the malformed NLRIs attribute tests in
+   "Fault Management" (Section 6.2.2) of [RFC7752] now encompass the new
+   TLV for the BGP-LS NLRI in this document.
+
+6.  Security Considerations
+
+   The new protocol extensions introduced in this document augment the
+   existing IGP topology information that can be distributed via BGP-LS
+   [RFC7752].  Procedures and protocol extensions defined in this
+   document do not affect the BGP security model other than as discussed
+   in "Security Considerations" (Section 8) of [RFC7752], i.e., the
+   aspects related to limiting the nodes and consumers with which the
+   topology information is shared via BGP-LS to trusted entities within
+   an administrative domain.
+
+   The TLV introduced in this document is used to propagate IGP-defined
+   information (see [RFC7883] and [RFC7884]).  The TLV represents
+   information used to set up S-BFD sessions.  The IGP instances
+   originating this information are assumed to support any required
+   security and authentication mechanisms (as described in [RFC7883] and
+   [RFC7884]).
+
+   Advertising the S-BFD Discriminators via BGP-LS makes it possible for
+   attackers to initiate S-BFD sessions using the advertised
+   information.  The vulnerabilities this poses and how to mitigate them
+   are discussed in [RFC7880].
+
+7.  References
+
+7.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,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
+              S. Ray, "North-Bound Distribution of Link-State and
+              Traffic Engineering (TE) Information Using BGP", RFC 7752,
+              DOI 10.17487/RFC7752, March 2016,
+              <https://www.rfc-editor.org/info/rfc7752>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc7880>.
+
+   [RFC7883]  Ginsberg, L., Akiya, N., and M. Chen, "Advertising
+              Seamless Bidirectional Forwarding Detection (S-BFD)
+              Discriminators in IS-IS", RFC 7883, DOI 10.17487/RFC7883,
+              July 2016, <https://www.rfc-editor.org/info/rfc7883>.
+
+   [RFC7884]  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>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+7.2.  Informative References
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
+              <https://www.rfc-editor.org/info/rfc5880>.
+
+Acknowledgements
+
+   The authors would like to thank Nan Wu for his contributions to this
+   work.  The authors would also like to thank Gunter Van de Velde and
+   Thomas Fossati for their reviews as well as Jeff Haas for his
+   shepherd review and Alvaro Retana for his AD review of this document.
+
+Authors' Addresses
+
+   Zhenbin Li
+   Huawei
+   Huawei Bld.
+   No.156 Beiqing Rd.
+   Beijing
+   100095
+   China
+   Email: lizhenbin@huawei.com
+
+
+   Shunwan Zhuang
+   Huawei
+   Huawei Bld.
+   No.156 Beiqing Rd.
+   Beijing
+   100095
+   China
+   Email: zhuangshunwan@huawei.com
+
+
+   Ketan Talaulikar (editor)
+   Arrcus, Inc.
+   India
+   Email: ketant.ietf@gmail.com
+
+
+   Sam Aldrin
+   Google, Inc.
+   Email: aldrin.ietf@gmail.com
+
+
+   Jeff Tantsura
+   Microsoft
+   Email: jefftant.ietf@gmail.com
+
+
+   Greg Mirsky
+   Ericsson
+   Email: gregimirsky@gmail.com