doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc8564.txt b/doc/rfc/rfc8564.txt
new file mode 100644
index 0000000..22b24e9
--- /dev/null
+++ b/doc/rfc/rfc8564.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          M. Zhang
+Request for Comments: 8564                           Huawei Technologies
+Updates: 7175, 7177                                        S. Pallagatti
+Category: Standards Track                                         Vmware
+ISSN: 2070-1721                                              V. Govindan
+                                                           Cisco Systems
+                                                              April 2019
+
+
+Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD)
+        in Transparent Interconnection of Lots of Links (TRILL)
+
+Abstract
+
+   Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD)
+   is designed to verify multipoint connectivity.  This document
+   specifies the support of P2MP BFD in Transparent Interconnection of
+   Lots of Links (TRILL).  Similar to TRILL point-to-point BFD, BFD
+   Control packets in TRILL P2MP BFD are transmitted using RBridge
+   Channel messages.  This document updates RFCs 7175 and 7177.
+
+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/rfc8564.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 1]
+
+RFC 8564                   P2MP BFD for TRILL                 April 2019
+
+
+Copyright Notice
+
+   Copyright (c) 2019 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 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Acronyms and Terminology  . . . . . . . . . . . . . . . . . .   3
+     2.1.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . .   3
+   4.  A New RBridge Channel Message for P2MP BFD  . . . . . . . . .   4
+   5.  Discriminators and Packet Demultiplexing  . . . . . . . . . .   4
+   6.  Tracking Active Tails . . . . . . . . . . . . . . . . . . . .   5
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
+
+1.  Introduction
+
+   TRILL supports multicast forwarding.  Applications based on TRILL
+   multicast may need quick detection of multicast failures using P2MP
+   BFD [RFC8562].  This document specifies TRILL support of P2MP BFD.
+
+   To use P2MP BFD, the head end needs to periodically transmit BFD
+   Control packets to all tails using TRILL multicast.  A new RBridge
+   Channel message is allocated for this purpose.
+
+   In order to execute the global protection of distribution used for
+   multicast forwarding [TRILL-TREES], the head needs to track the
+   active status of tails [RFC8563].  If the tail loses connectivity as
+   detected by not receiving the new RBridge Channel message from the
+   head, the tail should notify the head of the lack of multipoint
+
+
+
+Zhang, et al.                Standards Track                    [Page 2]
+
+RFC 8564                   P2MP BFD for TRILL                 April 2019
+
+
+   connectivity with unicast BFD Control packets.  These unicast BFD
+   Control packets are transmitted using the existing RBridge Channel
+   message assigned to BFD Control [RFC7175].
+
+   This document updates [RFC7177] as specified in Section 3 and updates
+   [RFC7175] as specified in Sections 4 and 5.
+
+2.  Acronyms and Terminology
+
+2.1.  Acronyms
+
+   Data Label:  VLAN or Fine-Grained Label [RFC7172].
+
+   BFD:   Bidirectional Forwarding Detection
+
+   P2MP:  Point to Multipoint
+
+   TRILL: Transparent Interconnection of Lots of Links or Tunneled
+          Routing in the Link Layer
+
+2.2.  Terminology
+
+   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.
+
+   Familiarity with [RFC6325], [RFC7175], and [RFC7178] is assumed in
+   this document.
+
+3.  Bootstrapping
+
+   The TRILL adjacency mechanism bootstraps the establishment of one-
+   hop TRILL BFD sessions [RFC7177].  Multi-hop sessions are expected to
+   be configured by the network manager.  A slight wording update to the
+   second sentence in Section 6 of [RFC7177] is required.
+
+   It currently reads:
+
+      If an RBridge supports BFD [RFC7175], it will have learned whether
+      the other RBridge has BFD enabled by whether or not a BFD-Enabled
+      TLV [RFC6213] was included in its Hellos.
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 3]
+
+RFC 8564                   P2MP BFD for TRILL                 April 2019
+
+
+   Now it should read:
+
+      If an RBridge supports BFD (see [RFC7175] and [RFC8564]), it will
+      have learned whether the other RBridge has BFD enabled by whether
+      or not a BFD-Enabled TLV [RFC6213] was included in its Hellos.
+
+   In addition, a normative reference to this document is added to RFC
+   7177 as a result of this update.
+
+4.  A New RBridge Channel Message for P2MP BFD
+
+   RBridge Channel protocol number 0x002 is defined for TRILL point-to-
+   point BFD Control packets in [RFC7175].  That RFC states that if the
+   M bit of the TRILL Header of the RBridge Channel packet containing a
+   BFD Control packet is nonzero, the packet is generally dropped.  In
+   P2MP BFD, the head is required to probe tails using multicast.  This
+   means the M bit will be set to 1.  For this reason, a new RBridge
+   Channel message (P2MP BFD Control), whose protocol code point is
+   0x007, is specified in this document.  An RBridge that supports P2MP
+   BFD MUST support the new RBridge Channel message for P2MP BFD.  The
+   capability to support the RBridge Channel message for P2MP BFD, and
+   therefore support performing P2MP BFD, is announced within the
+   RBridge Channel Protocols sub-TLV in Link State PDUs (LSPs)
+   [RFC7176].
+
+   As specified in [RFC7178], when the tail receives TRILL Data packets
+   sent as BFD RBridge Channel messages, it will absorb the packets
+   itself rather than deliver these packets to its attached end
+   stations.
+
+5.  Discriminators and Packet Demultiplexing
+
+   The processing in Section 3.2 of [RFC7175] generally applies except
+   that the test on the M bit in the TRILL Header is reversed.  If the M
+   bit is zero, the packet MUST be discarded.  If the M bit is one, it
+   is processed.
+
+   After the processing per Section 3.2 of [RFC7175], the tail
+   demultiplexes incoming BFD packets based on a combination of the
+   source address and My Discriminator as specified in [RFC8562].  In
+   addition to this combination, TRILL P2MP BFD requires that the tail
+   use the Data Label, which is either the inner VLAN or the Fine-
+   Grained Label [RFC7172], for demultiplexing.  If the tail needs to
+   notify the head about the failure of a multipath, the tail is
+   required to send unicast BFD Control packets using the same Data
+   Label as used by the head.
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 4]
+
+RFC 8564                   P2MP BFD for TRILL                 April 2019
+
+
+6.  Tracking Active Tails
+
+   According to [RFC8562], the head has a session of type MultipointHead
+   that is bound to a multipoint path.  Multipoint BFD Control packets
+   are sent by this session over the multipoint path, and no BFD Control
+   packets are received by it.  Each tail dynamically creates a
+   MultipointTail per a multipoint path.  MultipointTail sessions
+   receive BFD Control packets from the head over multipoint paths.
+
+   An example use is when a multicast tree root needs to keep track of
+   all the receivers as in [TRILL-TREES]; this can be done by
+   maintaining a session of type MultipointClient per receiver that is
+   of interest, as described in [RFC8563].  See [RFC8563] for detailed
+   operations of tracking active tails.
+
+7.  Security Considerations
+
+   Multipoint BFD provides its own authentication but does not provide
+   encryption (see the Security Considerations in [RFC8562]).  As
+   specified in this document, the point-to-multipoint BFD payloads are
+   encapsulated in RBridge Channel messages that have been extended by
+   [RFC7978] to provide security.  [RFC7978] provides encryption only
+   for point-to-point extended RBridge Channel messages, so its
+   encryption facilities are not applicable to this document.  However,
+   [RFC7978] provides stronger authentication than that currently
+   provided in BFD.  Thus, there is little reason to use the BFD
+   security mechanisms if authentication per [RFC7978] is in use.  It is
+   expected that a future TRILL document will provide for group keying;
+   when that occurs, the use of RBridge Channel security [RFC7978] will
+   be able to provide both encryption and authentication.
+
+   For general multipoint BFD security considerations, see [RFC8562].
+
+   For general RBridge Channel security considerations, see [RFC7178].
+
+8.  IANA Considerations
+
+   IANA has allocated the following from the Standards Action [RFC8126]
+   range of the "RBridge Channel Protocols" registry, which is part of
+   the "Transparent Interconnection of Lots of Links (TRILL) Parameters"
+   registry.
+
+          Protocol          Number
+          ----------------  ------
+          P2MP BFD Control  0x007
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 5]
+
+RFC 8564                   P2MP BFD for TRILL                 April 2019
+
+
+9.  References
+
+9.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>.
+
+   [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
+              Ghanwani, "Routing Bridges (RBridges): Base Protocol
+              Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
+              <https://www.rfc-editor.org/info/rfc6325>.
+
+   [RFC7172]  Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
+              D. Dutt, "Transparent Interconnection of Lots of Links
+              (TRILL): Fine-Grained Labeling", RFC 7172,
+              DOI 10.17487/RFC7172, May 2014,
+              <https://www.rfc-editor.org/info/rfc7172>.
+
+   [RFC7175]  Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee,
+              "Transparent Interconnection of Lots of Links (TRILL):
+              Bidirectional Forwarding Detection (BFD) Support",
+              RFC 7175, DOI 10.17487/RFC7175, May 2014,
+              <https://www.rfc-editor.org/info/rfc7175>.
+
+   [RFC7176]  Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
+              D., and A. Banerjee, "Transparent Interconnection of Lots
+              of Links (TRILL) Use of IS-IS", RFC 7176,
+              DOI 10.17487/RFC7176, May 2014,
+              <https://www.rfc-editor.org/info/rfc7176>.
+
+   [RFC7177]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
+              V. Manral, "Transparent Interconnection of Lots of Links
+              (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May
+              2014, <https://www.rfc-editor.org/info/rfc7177>.
+
+   [RFC7178]  Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
+              Ward, "Transparent Interconnection of Lots of Links
+              (TRILL): RBridge Channel Support", RFC 7178,
+              DOI 10.17487/RFC7178, May 2014,
+              <https://www.rfc-editor.org/info/rfc7178>.
+
+   [RFC7978]  Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent
+              Interconnection of Lots of Links (TRILL): RBridge Channel
+              Header Extension", RFC 7978, DOI 10.17487/RFC7978,
+              September 2016, <https://www.rfc-editor.org/info/rfc7978>.
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 6]
+
+RFC 8564                   P2MP BFD for TRILL                 April 2019
+
+
+   [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>.
+
+   [RFC8562]  Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
+              Ed., "Bidirectional Forwarding Detection (BFD) for
+              Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562,
+              April 2019, <https://www.rfc-editor.org/info/rfc8562>.
+
+   [RFC8563]  Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
+              Ed., "Bidirectional Forwarding Detection (BFD) Multipoint
+              Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
+              <https://www.rfc-editor.org/info/rfc8563>.
+
+9.2.  Informative References
+
+   [RFC6213]  Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV",
+              RFC 6213, DOI 10.17487/RFC6213, April 2011,
+              <https://www.rfc-editor.org/info/rfc6213>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [TRILL-TREES]
+              Zhang, M., Senevirathne, T., Pathangi, J., Banerjee, A.,
+              and A. Ghanwani, "TRILL: Resilient Distribution Trees",
+              Work in Progress, draft-ietf-trill-resilient-trees-09,
+              January 2018.
+
+Acknowledgements
+
+   The authors would like to thank Gayle Noble and Donald Eastlake 3rd
+   for their comments and suggestions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 7]
+
+RFC 8564                   P2MP BFD for TRILL                 April 2019
+
+
+Authors' Addresses
+
+   Mingui Zhang
+   Huawei Technologies
+   No.156 Beiqing Rd. Haidian District
+   Beijing  100095
+   China
+
+   Email: zhangmingui@huawei.com
+
+
+   Santosh Pallagatti
+   Vmware
+
+   Email: santosh.pallagatti@gmail.com
+
+
+   Vengada Prasad Govindan
+   Cisco Systems
+
+   Email: venggovi@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 8]
+