Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication
RFC 7740

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

• Versions
• 00
• 01
• 02
• 03
• 04

Internet Engineering Task Force (IETF)                          Z. Zhang
Request for Comments: 7740                                    Y. Rekhter
Category: Standards Track                               Juniper Networks
ISSN: 2070-1721                                              A. Dolganow
                                                          Alcatel-Lucent
                                                            January 2016

      Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP)
               Provider Tunnels with Ingress Replication

Abstract

   RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to
   support bidirectional customer multicast flows using a partial mesh
   of Multipoint-to-Multipoint (MP2MP) tunnels.  This document specifies
   how a partial mesh of MP2MP tunnels can be simulated using Ingress
   Replication.  This solution enables a service provider to use Ingress
   Replication to offer transparent bidirectional multicast service to
   its VPN customers.

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

   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/rfc7740.

Zhang, et al.                Standards Track                    [Page 1]
RFC 7740                 C-BIDIR Support with IR            January 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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Control State . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Forwarding State  . . . . . . . . . . . . . . . . . . . .   6
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     4.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

Zhang, et al.                Standards Track                    [Page 2]
RFC 7740                 C-BIDIR Support with IR            January 2016

1.  Introduction

   Section 11.2 of RFC 6513 ("Partitioned Sets of PEs") describes two
   methods of carrying Bidirectional PIM (BIDIR-PIM) [RFC5015] C-flow
   traffic over a provider core without using the core as the Rendezvous
   Point Link (RPL) or requiring Designated Forwarder election.

   With these two methods, all Provider Edges (PEs) of a particular VPN
   are separated into partitions, with each partition being all the PEs
   that elect the same PE as the Upstream PE with respect to the C-RPA
   (the Rendezvous Point Address in the customer's address space).  A PE
   must discard bidirectional C-flow traffic from PEs that are not in
   the same partition as the PE itself.

   In particular, Section 11.2.3 of RFC 6513 ("Partial Mesh of MP2MP
   P-Tunnels") guarantees the above discard behavior without using an
   extra PE Distinguisher Label by having all PEs in the same partition
   join a single MP2MP tunnel dedicated to that partition and use it to
   transmit traffic.  All traffic arriving on the tunnel will be from
   PEs in the same partition, so it will be always accepted.

   RFC 6514 specifies BGP encodings and procedures used to implement
   Multicast VPN (MVPN) as specified in RFC 6513, while the details
   related to MP2MP tunnels are specified in [RFC7582].

   RFC 7582 assumes that an MP2MP P-tunnel is realized either via BIDIR-
   PIM [RFC5015] or via MP2MP mLDP (Multipoint extensions for LDP)
   [RFC6388].  Each would require signaling and state not just on PEs,