doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc7891.txt b/doc/rfc/rfc7891.txt
new file mode 100644
index 0000000..234e1b6
--- /dev/null
+++ b/doc/rfc/rfc7891.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         J. Asghar
+Request for Comments: 7891                             IJ. Wijnands, Ed.
+Category: Standards Track                                S. Krishnaswamy
+ISSN: 2070-1721                                                 A. Karan
+                                                           Cisco Systems
+                                                                 V. Arya
+                                                            DIRECTV Inc.
+                                                               June 2016
+
+
+             Explicit Reverse Path Forwarding (RPF) Vector
+
+Abstract
+
+   The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496
+   can be included in a PIM Join Attribute such that the RPF neighbor is
+   selected based on the unicast reachability of the RPF Vector instead
+   of the source or Rendezvous Point associated with the multicast tree.
+
+   This document defines a new RPF Vector Attribute type such that an
+   explicit RPF neighbor list can be encoded in the PIM Join Attribute,
+   thus bypassing the unicast route lookup.
+
+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/rfc7891.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asghar, et al.               Standards Track                    [Page 1]
+
+RFC 7891      Explicit Reverse Path Forwarding (RPF) Vector    June 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
+   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
+   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   4.  Use of the PIM Explicit RPF Vector  . . . . . . . . . . . . .   4
+   5.  Explicit RPF Vector Attribute TLV Format  . . . . . . . . . .   5
+   6.  Mixed Vector Processing . . . . . . . . . . . . . . . . . . .   5
+   7.  Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . .   5
+   8.  PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . .   6
+   9.  Join Suppression  . . . . . . . . . . . . . . . . . . . . . .   6
+   10. Unsupported Explicit Vector Handling  . . . . . . . . . . . .   7
+   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
+   12. Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
+     13.1.  Normative References . . . . . . . . . . . . . . . . . .   8
+     13.2.  Informative References . . . . . . . . . . . . . . . . .   8
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asghar, et al.               Standards Track                    [Page 2]
+
+RFC 7891      Explicit Reverse Path Forwarding (RPF) Vector    June 2016
+
+
+1.  Introduction
+
+   The procedures in [RFC5496] define how an RPF Vector can be used to
+   influence the path selection in the absence of a route to the source.
+   The same procedures can be used to override a route to the source
+   when it exists.  It is possible to include multiple RPF Vectors in
+   the list where each router along the path will perform a unicast
+   route lookup on the first Vector in the attribute list.  Once the
+   router owning the address of the RPF Vector is reached, following the
+   procedures in [RFC5496], the RPF Vector will be removed from the
+   attribute list.  This will result in a 'loosely' routed path that
+   still depends on unicast reachability to the RPF Vector(s).
+
+   In some scenarios, the network administrators don't want to rely on
+   the unicast reachability to the RPF Vector address and want to build
+   a path strictly based on the RPF Vectors.  In that case, the RPF
+   Vectors represent a list of directly connected PIM neighbors along
+   the path.  For these Vectors, the router would not do a route lookup
+   in the unicast routing table.  These Vectors are referred to as
+   'Explicit' RPF Vector addresses.  If a router receiving an Explicit
+   RPF Vector does not have a PIM neighbor matching the Explicit RPF
+   Vector address, it does not fall back to loosely routing the Join.
+   Instead, it could process the packet and store the RPF Vector list so
+   that the PIM Join can be sent out as soon as the neighbor comes up.
+   Since the behavior of the Explicit RPF Vector differs from the
+   'loose' RPF Vector as defined in [RFC5496], a new attribute called
+   the Explicit RPF Vector is defined.
+
+   This document defines a new TLV in the PIM Join Attribute message
+   [RFC5384] for specifying the explicit path.
+
+2.  Specification of Requirements
+
+   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 [RFC2119].
+
+3.  Motivation
+
+   Some broadcast video transport networks use a multicast PIM Live-Live
+   resiliency model for video delivery based on PIM Source-Specific
+   Multicast (PIM-SSM) or PIM Any-Source Multicast (PIM-ASM).  Live-Live
+   implies using two active, spatially diverse multicast trees to
+   transport video flows from root to leaf multicast routers.  The leaf
+   multicast router receives two copies from the PIM multicast core and
+   will replicate one copy towards the receivers [RFC7431].
+
+
+
+
+
+Asghar, et al.               Standards Track                    [Page 3]
+
+RFC 7891      Explicit Reverse Path Forwarding (RPF) Vector    June 2016
+
+
+   One of the requirements of the PIM Live-Live resiliency model is to
+   ensure path diversity of the two active PIM trees in the core such
+   that they do not intersect to avoid a single point of failure.  IGP-
+   routed RPF paths of two PIM trees could be routed over the same
+   transit router and create a single point of failure.  It is useful to
+   have a way to specify the explicit path along which the PIM Join is
+   propagated.
+
+   How the Explicit RPF Vector list is determined is outside the scope
+   of this document.  For example, it may either be manually configured
+   by the network operator or procedures may be implemented on the
+   egress router to dynamically calculate the Vector list based on a
+   link-state database protocol, like OSPF or IS-IS.
+
+   Due to the fact that the leaf router receives two copies of the
+   multicast stream via two diverse paths, there is no need for PIM to
+   repair the broken path immediately.  It is up to the egress router to
+   either wait for the broken path to be repaired or build a new
+   explicit path using a new RPF Vector list.  Which method is applied
+   depends very much on how the Vector list was determined initially.
+   Double failures are not considered and are outside the scope of this
+   document.
+
+   This document describes the procedures to carry Explicit RPF Vectors
+   in PIM.  It is up to the mechanism(s) that produce the Explicit RPF
+   Vectors to ensure they are correct.  Existing mechanisms like
+   [MTRACE-V2] may be used to verify how the PIM tree was built.
+
+4.  Use of the PIM Explicit RPF Vector
+
+   Figure 1 provides an example multicast join path
+   R4->R3->R6->R5->R2->R1, where the multicast join is explicitly routed
+   to the source hop by hop using the Explicit RPF Vector list.  When
+   the R5-R6 link fails, the Join will NOT take an alternate path.
+
+                  [S]---(R1)--(R2)---(R3)--(R4)---[R]
+                         <---   |      |  ---
+                            |   |      |  |
+                            | (R5)---(R6) |
+                            - (S,G) Join -
+                                |      |
+                                |      |
+                              (R7)---(R8)
+
+                                 Figure 1
+
+
+
+
+
+
+Asghar, et al.               Standards Track                    [Page 4]
+
+RFC 7891      Explicit Reverse Path Forwarding (RPF) Vector    June 2016
+
+
+   In comparison, when the procedures specified in [RFC5496] are used,
+   if the R5-R6 link fails, then the Join may be rerouted using the
+   R6-R8-R7 path to reach R5.
+
+5.  Explicit RPF Vector Attribute TLV Format
+
+       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
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |F|E| Type      | Length        |        Value
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
+
+                                 Figure 2
+
+   F bit:  'Transitive Attribute' bit.  The F bit MUST be set to 0.
+      Otherwise, there could be loops.
+
+   E bit:  'End of Attributes' bit.  If the E bit is set, then this is
+      the last TLV specified in the list.
+
+   Type:  4 (Explicit RPF Vector)
+
+   Length:  The length depending on the Address Family (IPv4 or IPv6) of
+      the Encoded-Unicast address.
+
+   Value:  Encoded-Unicast address.  This SHOULD be a valid IPv4 or IPv6
+      address of an upstream router.
+
+6.  Mixed Vector Processing
+
+   The Explicit RPF Vector Attribute does not impact or restrict the
+   functionality of other RPF Vector Attributes in a PIM Join.  It is
+   possible to mix Vectors of different types such that some part of the
+   tree is explicit and other parts are loosely routed.  RPF Vectors are
+   processed in the order in which they are specified.
+
+7.  Conflicting RPF Vectors
+
+   It is possible that a PIM router has multiple downstream neighbors.
+   If for the same multicast route there is an inconsistency between the
+   Explicit RPF Vector lists provided by the downstream PIM neighbor,
+   the procedures as documented in Section 3.3.3 of [RFC5384] apply.
+
+   The conflict resolution procedures in Section 3.3.3 of [RFC5384] only
+   apply to attributes of the same Join Attribute type.  Join Attributes
+   that have a different type can't be compared because the content of
+   the Join Attribute may have a totally different meaning and/or
+   encoding.  This may cause a problem if a mix of Explicit RPF Vectors
+
+
+
+Asghar, et al.               Standards Track                    [Page 5]
+
+RFC 7891      Explicit Reverse Path Forwarding (RPF) Vector    June 2016
+
+
+   (this document) and 'loose' RPF Vectors [RFC5496] is received from
+   two or more downstream routers.  The order in which the RPF Vectors
+   are encoded may be different, and/or the combination of RPF Vectors
+   may be inconsistent.  The procedures in Section 3.3.3 of [RFC5384]
+   would not resolve the conflict.  The following procedures MUST be
+   applied to deal with this scenario.
+
+   When a PIM Join with a Join Attribute list is received from a
+   downstream neighbor, the router MUST verify that the order in which
+   the RPF Vector types appear in the PIM Join Attribute list matches
+   what is stored as the Join Attribute list for reaching the source or
+   Rendezvous Point listed in the PIM Join.  Once it is determined that
+   the RPF Vector types on the stack are equal, the content of the RPF
+   Vectors MUST be compared ([RFC5384]).  If it is determined that there
+   is either a conflict with RPF Vector types or the RPF Vector content,
+   the router uses the RPF Vector stack from the PIM adjacency with the
+   numerically smallest IP address.  In the case of IPv6, the link-local
+   address will be used.  When two neighbors have the same IP address,
+   either for IPv4 or IPv6, the interface index MUST be used as a tie
+   breaker.  It's RECOMMENDED that the router doing the conflict
+   resolution log a message.
+
+8.  PIM Asserts
+
+   Section 3.3.3 of [RFC5496] specifies the procedures for how to deal
+   with PIM Asserts when RPF Vectors are used.  The same procedures
+   apply to the Explicit RPF Vector.  There is a minor behavioral
+   difference: the route 'metric' that is included in the PIM Assert
+   should be the route metric of the first Explicit RPF Vector address
+   in the list.  However, the first Explicit Vector should always be
+   directly connected, so the metric may likely be zero.  The metric
+   will therefore not be a tie breaker in the PIM Assert selection
+   procedure.
+
+9.  Join Suppression
+
+   Section 3.3.4 of [RFC5496] specifies the procedures for how to apply
+   Join Suppression when an RPF Vector Attribute is included in the PIM
+   Join.  The same procedure applies to the Explicit RPF Vector
+   Attribute.  The procedure MUST match against all the Explicit RPF
+   Vectors in the PIM Join before a PIM Join can be suppressed.
+
+
+
+
+
+
+
+
+
+
+Asghar, et al.               Standards Track                    [Page 6]
+
+RFC 7891      Explicit Reverse Path Forwarding (RPF) Vector    June 2016
+
+
+10.  Unsupported Explicit Vector Handling
+
+   The F bit MUST be set to 0 in all Explicit RPF Vectors in case the
+   upstream router receiving the Join does not support the TLV.  As
+   described in Section 3.3.2 of [RFC5384], routers that do not
+   understand the type of a particular attribute that has the F bit
+   clear will discard it and continue to process the Join.
+
+   This processing is particularly important when the routers that do
+   not support the Explicit RPF TLV are identified as hops in the
+   Explicit RPF list because failing to remove the RPF Vectors could
+   cause upstream routers to send the Join back toward these routers
+   causing loops.
+
+   As the administrator is manually specifying the path that the Joins
+   need to be sent on, it is recommended that the administrator computes
+   the path to include routers that support the Explicit Vector and
+   check that the state is created correctly on each router along the
+   path.  Tools like mtrace can be used for debugging and to ensure that
+   the Join state is setup correctly.
+
+11.  IANA Considerations
+
+   In the "PIM Join Attribute Types" registry, IANA has assigned the
+   value 4 to the Explicit RPF Vector Attribute.
+
+12.  Security Considerations
+
+   Security of the Explicit RPF Vector Attribute is only guaranteed by
+   the security of the PIM packet, so the security considerations for
+   PIM Join packets as described in PIM-SM [RFC7761] apply here.  A
+   malicious downstream node can attempt a denial-of-service attack by
+   sending PIM Join packets with invalid addresses listed in the RPF
+   Vector stack with an intent to stop the propagation of the Joins to
+   the correct upstream node.  Another denial-of-service attack would be
+   a malicious downstream node targeting all Joins to a specific node
+   with an intent to overload the bandwidth on that node by making it
+   responsible for forwarding multicast traffic for more streams that it
+   can handle.  In order to minimize the risk of a denial-of-service
+   attack from forged PIM Join packets with Explicit RPF Vector stack,
+   it should be used within a single trusted management domain.
+
+   If a router finds that it cannot use the Vector list due to the next
+   hop router not being a PIM neighbor, it may log an error.  Also, if a
+   router is receiving two conflicting Vectors, it may log an error.  It
+   is up to the mechanisms that produced the Explicit RPF Vector to
+   ensure that the PIM tree is built correctly and to monitor any error
+   logs.
+
+
+
+Asghar, et al.               Standards Track                    [Page 7]
+
+RFC 7891      Explicit Reverse Path Forwarding (RPF) Vector    June 2016
+
+
+13.  References
+
+13.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>.
+
+   [RFC5384]  Boers, A., Wijnands, I., and E. Rosen, "The Protocol
+              Independent Multicast (PIM) Join Attribute Format",
+              RFC 5384, DOI 10.17487/RFC5384, November 2008,
+              <http://www.rfc-editor.org/info/rfc5384>.
+
+   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
+              Forwarding (RPF) Vector TLV", RFC 5496,
+              DOI 10.17487/RFC5496, March 2009,
+              <http://www.rfc-editor.org/info/rfc5496>.
+
+   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
+              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
+              Multicast - Sparse Mode (PIM-SM): Protocol Specification
+              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
+              2016, <http://www.rfc-editor.org/info/rfc7761>.
+
+13.2.  Informative References
+
+   [MTRACE-V2]
+              Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2:
+              Traceroute Facility for IP Multicast", Work in Progress,
+              draft-ietf-mboned-mtrace-v2-13, June 2016.
+
+   [RFC7431]  Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
+              Decraene, "Multicast-Only Fast Reroute", RFC 7431,
+              DOI 10.17487/RFC7431, August 2015,
+              <http://www.rfc-editor.org/info/rfc7431>.
+
+Acknowledgements
+
+   The authors would like to thank Vatsa Kumar, Nagendra Kumar, and
+   Bharat Joshi for their comments on the document.
+
+
+
+
+
+
+
+
+
+
+Asghar, et al.               Standards Track                    [Page 8]
+
+RFC 7891      Explicit Reverse Path Forwarding (RPF) Vector    June 2016
+
+
+Authors' Addresses
+
+   Javed Asghar
+   Cisco Systems
+   725, Alder Drive
+   Milpitas, CA  95035
+   United States
+
+   Email: jasghar@cisco.com
+
+
+   IJsbrand Wijnands (editor)
+   Cisco Systems
+   De Kleetlaan 6a
+   Diegem  1831
+   Belgium
+
+   Email: ice@cisco.com
+
+   Sowmya Krishnaswamy
+   Cisco Systems
+   3750 Cisco Way
+   San Jose, CA  95134
+   United States
+
+   Email: sowkrish@cisco.com
+
+
+   Apoorva Karan
+   Cisco Systems
+   3750 Cisco Way
+   San Jose, CA  95134
+   United States
+
+   Email: apoorva@cisco.com
+
+
+   Vishal Arya
+   DIRECTV Inc.
+   2230 E Imperial Hwy
+   El Segundo, CA  90245
+   United States
+
+   Email: varya@directv.com
+
+
+
+
+
+
+
+Asghar, et al.               Standards Track                    [Page 9]
+