Network Working Group                                          J. Asghar
Internet-Draft                                         IJ. Wijnands, Ed.
Intended status: Standards Track                         S. Krishnaswamy
Expires: August 5, October 28, 2016                                       A. Karan
                                                           Cisco Systems
                                                                 V. Arya
                                                            DIRECTV Inc.
                                                        February 2,
                                                          April 26, 2016

                          Explicit RPF Vector
               draft-ietf-pim-explicit-rpf-vector-08.txt
               draft-ietf-pim-explicit-rpf-vector-09.txt

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 Randezvous 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,
   bypassing the unicast route lookup.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 5, October 28, 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Use of the PIM Explicit RPF Vector  . . . . . . . . . . . . .   4
   5.  Explicit RPF Vector Attribute TLV Format  . . . . . . . . . .   4
   6.  Mixed Vector Processing . . . . . . . . . . . . . . . . . . .   5
   7.  Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . .   5
   8.  PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Join Suppression  . . . . . . . . . . . . . . . . . . . . . .   6
   10. Unsupported Explicit Vector Handling  . . . . . . . . . . . .   6
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   12. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     14.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     14.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The procedures in [RFC5496] define how a 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 adminstrators 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 [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 SSM or PIM ASM.
   Live-Live implies using 2 active spatially diverse multicast trees to
   transport video flows from root to leaf multicast routers.  The leaf
   multicast router receives 2 copies from the PIM multicast core and
   will replicate 1 copy towards the receivers [RFC7431].

   One of the requirements of the PIM Live-Live resiliency model is to
   ensure path-diversity of the 2 active PIM trees in the core such that
   they do not intersect to avoid a single point of failure.  IGP routed
   RPF paths of 2 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
   [I-D.ietf-mboned-mtrace-v2] may be used to verify how the PIM tree
   was build.

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
   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

   In comparison, when [RFC5496] procedures are used, if R5-R6 link
   fails then the join may be re-routed using 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:  The F bit MUST be set to 0.  Otherwise there could be loops.

   E bit:  End of Attributes.  If this bit is set then this is the last
      TLV specified in the list.

   Type:  The Vector Attribute type is TBD1.

   Length:  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

   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 [RFC5384] apply.

   The conflict resolution procedures in section 3.3.3 [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
   (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 [RFC5384] would
   not resolve the conflict.  The following procedures MUST be applied
   to deal with this scenario.

   When a PIM Join with 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
   Randezvous 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
   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 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 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.

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 explcit 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

   A new attribute (TBD1) type from the "PIM Join Attribute Types"
   registry needs to be assigned by IANA for the Explicit RPF Vector
   attribute.  The proposed value 4.

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 [I-D.ietf-pim-rfc4601bis]
   apply here.  Inorder  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 minimize stop the risk propogation
   of the joins to the correct upstream node.  Another denial of service
   attack would be a malicious downstream node
   injecting targeting all joins to a
   specific node with an incorrect Explicit RPF vector stack, intent to overload the bandwidth on that node
   by making it should be used
   within a single trusted management domain responsible for forwarding multicast traffic for more
   streams that it can handle.  Inorder to minimize the risks risk of a denial
   of service attacks from forged PIM Join packets. 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 upto the mechanisms that produced the Explicit RPF vector to
   ensure that the the PIM tree is built correctly and to monitor any
   error logs.

13.  Acknowledgments

   The authors would like to thank Vatsa Kumar, Nagendra Kumar and
   Bharat Joshi for the comments on the document.

14.  References

14.1.  Normative References

   [I-D.ietf-pim-rfc4601bis]
              Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, J., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", draft-ietf-pim-rfc4601bis-06 (work in
              progress), August 2015.

   [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>.

14.2.  Informative References

   [I-D.ietf-mboned-mtrace-v2]
              Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2:
              Traceroute Facility for IP Multicast", draft-ietf-mboned-
              mtrace-v2-12 (work in progress), October 2015.

   [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>.

Authors' Addresses

   Javed Asghar
   Cisco Systems
   725, Alder Drive
   Milpitas  CA 95035
   USA

   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
   USA

   Email: sowkrish@cisco.com

   Apoorva Karan
   Cisco Systems
   3750 Cisco Way
   San Jose  CA 95134
   USA

   Email: apoorva@cisco.com

   Vishal Arya
   DIRECTV Inc.
   2230 E Imperial Hwy
   El Segundo  CA  90245
   USA

   Email: varya@directv.com