Explicit Reverse Path Forwarding (RPF) Vector
RFC 7891

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09

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